cloudtools / stacker

An AWS CloudFormation Stack orchestrator/manager.
http://stacker.readthedocs.io/en/stable/
BSD 2-Clause "Simplified" License
711 stars 167 forks source link

Regression: Locked stacks do not properly construct dependency list. #745

Closed mromaszewicz closed 4 years ago

mromaszewicz commented 4 years ago

Consider this scenario: Stack A has output Foo. Stack B depends on A::Foo

This is expected to work: stacks:

- name: A
   enabled: true
   class_path: <something>
- name: B
   enabled: true
   locked: true
   class_path: <something>
   variables:
     SomeInput: ${output A::Foo}

It is expected that stack A must be in the dependency DAG before stack B, but this doesn't happen as of stacker 1.5.0. It works properly in stacker 1.4.1

In stacker 1.5.0, dependencies are built correctly if stack B is not locked. However, at creation time, it should not matter whether a stack is locked or not.

This is easiest to reproduce by having a stacker file with 2 stacks in it, and swap their order if it works initially. It will fail in 1.5.0+

mromaszewicz commented 4 years ago

Please see my pull request.

The issue is that when a stack is locked, its requires list was overridden to empty, however, this is not a valid optimization at stack creation time.

My fix removes that optimization, and locked stacks have requirements, like unlocked stacks. It means they are ordered correctly in the DAG at creation time.