Open Stack

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.