[Test] Fix intermittent failure in test_dynamic_file_system_update.

[gmarciani]

Description of changes

Fix intermittent failure in test_dynamic_file_system_update.
The test could fail because the external EFS has chances to deploy mount targets in AZs that are not used by the cluster.
With this fix we deploy the storage in the private subnets used by the compute nodes (one per AZ), so that the external EFS has a mount target in every AZ used by the cluster.

Tests

SUCCEEDED

test-suites:
  update:
    test_update.py::test_dynamic_file_systems_update:
      dimensions:
        - instances:
            - c5.xlarge
          oss:
            - alinux2023
          regions:
            - us-east-1
          schedulers:
            - slurm

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[hehe7318]

Looks not good to me to change none test file cloudformation/storage/storage-stack.yaml, just for fixing intermittent test failure.
What do you think?

[gmarciani]

Looks not good to me to change none test file cloudformation/storage/storage-stack.yaml, just for fixing intermittent test failure.
What do you think?

@hehe7318 that's an interesting point. I would agree with you if the change were not backward compatible.
In this case, the change is backward compatible, we are just making the template able to deploy in single-AZ fashion.
We are making the template more flexible, we are not reducing its capabilities.

Also, let's think about the alternative approach where we do not make any change to the template. In this case we to deploy the storage stack with multi-AZ fashion forcefully, but using just one AZ, which basically means that we are paying to an EFS mount target that is never used.

What do you think?

[hehe7318]

Looks not good to me to change none test file cloudformation/storage/storage-stack.yaml, just for fixing intermittent test failure.
What do you think?

@hehe7318 that's an interesting point. I would agree with you if the change were not backward compatible. In this case, the change is backward compatible, we are just making the template able to deploy in single-AZ fashion. We are making the template more flexible, we are not reducing its capabilities.

Also, let's think about the alternative approach where we do not make any change to the template. In this case we to deploy the storage stack with multi-AZ fashion forcefully, but using just one AZ, which basically means that we are paying to an EFS mount target that is never used.

What do you think?

Convinced me! Approved!