[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