Comment 12 for bug 1291905

I see from IRC scrollback that I was not especially clear. I've done a more thorough analysis of the templates - which BTW are incredibly difficult to read because there's a notCompute0 and a NovaCompute0 (why??? name things after what they are, not what they aren't), and because stuff moves around unnecessarily in the file (It looks like NovaCompute1 replaces NovaCompute0, but in fact NovaCompute0 has just moved elsewhere in the file). It appears the change you're trying to make is to add a new server (NovaCompute1) with a new WaitCondition and WaitConditionHandle, while not modifying the previous server.

What you want to do instead is for NovaCompute0CompletionHandle to have been an OS::Heat::UpdateWaitConditionHandle instead of an AWS::CloudFormation::WaitConditionHandle for the new server (I think it's OK if you create a new WaitCondition; it's probably not important either way). Unlike a WaitConditionHandle, an UpdateWaitConditionHandle (which stores the data for the WaitCondition) will get replaced (i.e. the data cleared) during an update. The Count on the WaitCondition should be the number of servers you are adding and/or replacing. So if NovaCompute0 is not being replaced, you only need/want a Count of 1 (for NovaCompute1, which is new).

You'll need to rearrange the dependencies too, obviously.

The other workaround would be to do a two-stage update. Add the WaitConditionHandle in the first update, then add the server and the WaitCondition in a subsequent update.