Open Stack

On 29/10/14 09:28, Steve Baker wrote:
> 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)
>

I've looked at the tripleo templates now, and they create ports which 
are resources in their own right, so switching to 
replacement_policy:AUTO is entirely appropriate.  However in most 
templates the vast majority of port resources are just to define a 
simple server/port/floating-IP combo. Therefore I think there is a good 
argument for the default REPLACE_ALWAYS causing the least problems for 
the majority of cases.

> [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/d0bd490a/attachment.html>