Comment 3 for bug 1521944

Revision history for this message
Steven Hardy (shardy) wrote :

Ok, here's my analysis of what is happening here:

1. We have a template which creates a Net/Subnet and a Port in two different nested stacks:

resources:
  network:
    type: MY::Net

  port:
    type: MY::Port
    depends_on: network

This works fine on create, as we create the network->subnet->port

2. We update the stack, switching MY::Net and MY::Port to a noop implementation

This is a stealth delete, applied as a update, so we traverse the graph in the normal (forward) way, e.g

Update My::Net causes delete of subnet, then port - which fails, because MY::Port is still the previous state, containing a port.

The example templates use depends_on instead of wiring the actual subnet ID from one nested stack to the other, but I think the same issue exists regardless. This is a kind of odd corner case where we're asking for an update, but really deleting things.

A solution would be to ensure the network, subnet and port resources were always in the same heat template, as then we'd be able to properly manage the dependencies.

In terms of workarounds and recovery, I'm not sure - the main thing would be a user-initiated way to force reverting to the backup stack, but we'd need a way to not do that in the normal rollback method (because that's just a stack update, which will have this same problem).