OS::Neutron::Port nested within AWS::CloudFormation::Stack is updated despite unchanged nested template

[Joe D'Andrea]

Given a parent template with a resource effectively of type AWS::CloudFormation::Stack (but with file scheme support added), and a nested template containing a OS::Nova::Server, OS::Neutron::Port, and OS::Neutron::FloatingIP, changing a property in the parent template and performing a stack-update results in the nested OS::Neutron::Port being re-created instead of updated.

See http://paste.openstack.org/show/119498/ for a detailed description.

In this example, we arbitrarily change the timeout_in_minutes property of the parent stack and leave the nested stack unchanged.

[Steven Hardy (shardy)]

I believe this is working as expected, due to the default replacement policy of the port resource:

https://github.com/openstack/heat/blob/master/heat/engine/resources/neutron/port.py#L165

I'd agree that REPLACE_ALWAYS seems like a pretty weird default, but setting it to AUTO sounds like it will give the behavior you want. Perhaps the bug is that the default is wrong, but I'm assuming there's some historical reason why it's been done like that.

[Joe D'Andrea (jdandrea)]

Ah, interesting. I

"REPLACE_ALWAYS will replace the port regardless of any property changes." What if there are _no_ property changes? Then again, it does read: "Policy on how to respond to a stack-update for this resource," and this was indeed a stack update, even though the resource was unchanged.

I wonder what happens to any existing connections, like a Floating IP? Does the IP get reassigned, for instance? I'll find out.

Meanwhile, I will try AUTO!

[Joe D'Andrea (jdandrea)]

AUTO works as expected when creating a nested Port, then updating any property in the parent template: The Port resource is unchanged.

[Steve Baker (steve-stevebaker)]

The default REPLACE_ALWAYS is to work around poor nova/neutron interaction with regards to ports, and because if update creates a new server, the new server cannot share the port with the old server.

Basically modelling a port as a resource in heat really doesn't work well with stack updates. REPLACE_ALWAYS works around the most common issues, but not all (doing a REPLACE_ALWAYS stack-update on a port with a fixed_ip won't work as the IP address is exclusive)

The longer term fix will be a blueprint which lets all network interface options to be defined within OS::Nova::Server

[Joe D'Andrea (jdandrea)]

I appreciate all of that! Very good to know. Modeling these resources is not always (or often) trivial.

[Joe D'Andrea (jdandrea)]

Hi! Checking in on this one again. Are OS::Neutron::Port updates not possible in Icehouse? I don't see replacement_policy in Icehouse.

To your point, "Basically modeling a port as a resource in heat really doesn't work well with stack updates." I want to confirm if I can't model Neutron ports in Heat / Icehouse (Stable) if I'm expecting to update the stack.

[Steve Baker (steve-stevebaker)]

You can update the stack, but you may need to limit that to changes which don't cause the server to be replaced. Although I'm not sure exactly what Nova's behaviour is in Icehouse WRT deleting ports that it didn't create.

In Kilo there is a blueprint to manage this better https://review.openstack.org/#/c/130093/

[Launchpad Janitor (janitor)]

[Expired for heat because there has been no activity for 60 days.]