Actually it's worse than just deleting the port, HARestarter deletes *itself* when restarting an instance.
I'm attaching an example template, where if you trigger the restart by hitting the output URL, the HARestarter resource itself is deleted and recreated. This is a problem because it creates a new signal URL, and also deletes and recreates the keystone user associated with the SignalResponder.
It seems that we need a way to make HARestarter break the dependency chain, such that on recreating a resource, we don't walk the tree and delete all dependent resources too.
Actually it's worse than just deleting the port, HARestarter deletes *itself* when restarting an instance.
I'm attaching an example template, where if you trigger the restart by hitting the output URL, the HARestarter resource itself is deleted and recreated. This is a problem because it creates a new signal URL, and also deletes and recreates the keystone user associated with the SignalResponder.
It seems that we need a way to make HARestarter break the dependency chain, such that on recreating a resource, we don't walk the tree and delete all dependent resources too.