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 _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev