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

Steven Hardy shardy at redhat.com
Wed Oct 29 10:22:55 UTC 2014


On Wed, Oct 29, 2014 at 09:52:34AM +1300, Steve Baker wrote:
>    On 29/10/14 09:28, Steve Baker wrote:
<snip>
>    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.

Thanks for the information Steve, I've posted a patch moving the tripleo
templates to AUTO, which should work around the immediate problem there.

So, let me just try to clarify how we expect updates to work with the
current default, lets take a simple example template:

https://github.com/openstack/heat-templates/blob/master/hot/servers_in_new_neutron_net.yaml#L75

Here, we have two servers, both referencing ports, with both having a
floating IP referencing the ports.

Am I reading this right, it's impossible to update that template, as it's
currently written, without always replacing both servers?

If true, that to me is an indicator that REPLACE_ALWAYS is not a sane
default.

Can you clarify how updates are expected to work when you have the "simple
server/port/floating-IP combo", other than perhaps hiding the combo in a
nested stack so we don't try to update it?

It seems like we should be able to do the following (on a template
containing a simple server/port/floating-IP combo):

1. Update the stack without changing the template.  This shouldn't change
anything.

2. Add another resource (e.g maybe another server/port/floating-IP) without
destroying the first.

If we can't support both of those by default, updates are terminally broken
for nearly all users IMO - but are we saying the rich network properties
will solve that?

Thanks for any further insight you can provide :)

Cheers,

Steve



More information about the OpenStack-dev mailing list