On 29/10/14 23:22, Steven Hardy wrote:
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.
Not at all. The networks property of OS::Nova::Server is update_allowed=True (sub-properties of networks are not, but that only affects the generated documentation. This should be fixed)
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.
AUTO: nothing changes, all good

REPLACE_ALWAYS: all ports are replaced, Server and FloatingIP are updated without replacement. The port churn is not ideal, but it does work.

rich network property: same as AUTO, nothing changes, all good
2. Add another resource (e.g maybe another server/port/floating-IP) without
destroying the first.
Same as above for the existing resources. New resources are created as normal
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 :)

Here are some other update scenarios

3. Update the stack with a change which causes server replacement

AUTO: new server is created while old server still exists. Attempt to attach port to new server which fails due to port still in use. If this was fixed then the port will disappear anyway, as nova will delete it when the old server is deleted

REPLACE_ALWAYS: new port is attached to new server, old port is deleted when old server is deleted (whether by nova or heat)

rich network property: same as REPLACE_ALWAYS


4. port with fixed IP address. Update the stack without changing the template

AUTO: nothing changes, all good

REPLACE_ALWAYS: new port with same fixed IP is created, fails since IP address is already claimed by old port

rich network property: same as AUTO, nothing changes, all good


5. port with fixed IP address. Update the stack and change the fixed IP

AUTO: port is replaced, Server and FloatingIP are updated without replacement.

REPLACE_ALWAYS: same as AUTO

rich network property: same as AUTO


6. port with fixed IP address. Update the stack with a change which causes server replacement, but no change to fixed IP address

AUTO: same problems as 3. AUTO

REPLACE_ALWAYS: Same problem as 4. REPLACE_ALWAYS

rich network property: server create/update/delete logic also manages port create/update/delete, so it can do the required juggle to move the fixed IP from the old port to the new port


So to summarize these scenarios

Works fine
----------
AUTO: scenarios where the server isn't replaced and no fixed IP is defined on the port REPLACE_ALWAYS: scenarios where the server is replaced and no fixed IP is defined on the port
rich network property: all scenarios

Sub-optimal but works
---------------------
REPLACE_ALWAYS: scenarios where the server isn't replaced and no fixed IP is defined on the port

Doesn't work
------------
AUTO: all scenarios where the server is replaced
REPLACE_ALWAYS: all scenarios where the port has a fixed IP address which doesn't change on stack update

So I still think REPLACE_ALWAYS is still the least worst default, and rich network property will improve the situation.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to