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


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?


The commit does a reasonable job of explaining the whole sorry situation


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
OpenStack-dev mailing list

Reply via email to