[openstack-dev] [heat][nova] Changing default replacement_policy for Neutron port?

Steve Baker sbaker at redhat.com
Tue Oct 28 20:28:22 UTC 2014


On 29/10/14 06:51, Steven Hardy wrote:
> Hi all,
>
> So I've been investigating bug #1383709, which has caused me to run into a
> bad update pattern involving OS::Neutron::Port
>
> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port
>
> I'm not quite clear on the history, but for some reason, we have a
> "replacement_policy" property, unlike all other resources, and it defaults
> to replacing the resource every time you update, unless you pass "AUTO" to
> the property.
>
> I'm sure there's a good reason for this, but on the face of it, it seems to
> be a very unsafe and inconvenient default when considering updates?
>
> The problem (which may actually be the cause the bug #1383709) is the UUID
> changes, so you don't only replace the port, you replace it and everything
> that references it, which makes the Port resource a landmine of
> HARestarter-esque proportions ;)
>
> Can anyone (and in particular stevebaker who initally wrote the code) shed
> any light on this?  Can we just flip the default to AUTO, as it seems to be
> a more desirable default for nearly all users?
>
> Thanks!
>
>
The commit does a reasonable job of explaining the whole sorry situation

https://review.openstack.org/#/c/121693/

This was an attempt to improve port modelling enough for Juno while nova 
bug #1158684 [1] remains unfixed.

If we defaulted to replacement_policy:AUTO then we have the 2 issues 
when a server is replaced on stack update [3][1]

If we keep the current default then we have the symptoms of bug #1383709.

Both options suck and there is no way of always doing the right thing, 
which is why replacement_policy exists - to push this decision to the 
template author.

I've come to the conclusion that ports shouldn't be modelled as 
resources at all; they sometimes represent exclusive resources (fixed 
IPs) and their dependencies with servers sometimes goes both ways. To 
fix this properly I've written a Kilo spec for blueprint 
rich-network-prop [2]

Before we switch the default to AUTO maybe we could investigate getting 
REPLACE_ALWAYS to interact better with ResourceGroup (or the tripleo 
templates which use it)

[1] https://bugs.launchpad.net/nova/+bug/1158684
[2] https://review.openstack.org/#/c/130093/
[3] https://bugs.launchpad.net/heat/+bug/1301486
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141029/80acca6a/attachment.html>


More information about the OpenStack-dev mailing list