On 29/10/14 06:51, Steven Hardy wrote:
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
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  remains unfixed.
If we defaulted to replacement_policy:AUTO then we have the 2 issues
when a server is replaced on stack update 
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
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
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)
OpenStack-dev mailing list