How to handle dependencies? about aws-control-tower-customizations HOT 6 CLOSED

Yes, we use that attribute in the custom function (which controls stack creation) in exactly the same manner,. i.e. to ensure a parent stack exists before the child is created.

from aws-control-tower-customizations.

CloudFormation will actually create resources in parallel to the extent possible. But sometimes, certain resources must be created or deleted prior to another. The DependsOn attribute is used in cases where creation of a specific resource must follow another, and this dependency is not obvious as in the case of an implicit reference from the child (call this resource 'B') to a parent resource (call this resource 'A'. So resource A is created before B. While this serialized execution order will be slower than parallel, it is required in some cases as I have previously mentioned. For example, an EC2 instance with a public IP depends on an existing Internet Gateway attachment, so to ensure CloudFormation is aware of the dependency and executes in a consistent manner the DependsOn attribute is used in the EC2 instance resource to reference the IGW attachment resource.

If the resources or stacks are in fact independent of each other, the attribute should not be used and the default CloudFormation behavior used.

from aws-control-tower-customizations.

Thanks @cgswong!

Sorry I probably wasn't clear enough in my questioning. I was refering to the stacksets creation coming from the manifest.yaml file. Specifically the order of which the stacks in the cloudformation_resource gets deployed by the codepipeline. I was hoping for something like this would be an option:

...
cloudformation_resources:
  - name: EnableConfig
    template_file: templates/config.template
    parameter_file: parameters/config.template
    deploy_method: stack_set
    regions:
      - some-region-not-available-yet-in-guardrails
    deploy_to_ou:
      - Custom

  - name: EnableConfigRules
    template_file: templates/config-rules.template
    parameter_file: parameters/config-rules.template
    deploy_method: stack_set
    regions:
      - some-region-not-available-yet-in-guardrails
    deploy_to_ou:
      - Custom
    depends_on: 
      - EnableConfig
...

In this examble it makes sense to enable Config before adding Config rules.
Hope it makes better sense.

from aws-control-tower-customizations.

Ok. I just don't see the attribute depends_on in the manifest.py file.

But I did a test and saw that the stacksets are created in order and each stackset is first applied when the previous succeeds. That's great, so we avoid race conditions.

from aws-control-tower-customizations.

Correct, the StackSets under cloudformation_resources are deployed in sequence.
Thanks Stuart (@cgswong) for helping out.
Mikkel (@miqueloi), if your question has been answered, shall we close this issue? Please advise.
Thanks.

from aws-control-tower-customizations.

My questions have been answered, thanks!

from aws-control-tower-customizations.