[openstack-dev] [Heat] [TripleO] Rolling updates spec re-written. RFC

Jay Dobies jason.dobies at redhat.com
Wed Feb 5 15:16:32 UTC 2014


>> First, I don't think RollingUpdatePattern and CanaryUpdatePattern should be 2 different entities. The second just looks like a parametrization of the first (growth_factor=1?).
>
> Perhaps they can just be one. Until I find parameters which would need
> to mean something different, I'll just use UpdatePattern.

I wondered about this too. Maybe I'm just not as familiar with the 
terminology, but since we're stopping on all failures both function as a 
canary in testing the waters before doing the update. The only 
difference is the potential for acceleration.

As for an example of an entirely different strategy, what about the idea 
of standing up new instances with the updates and then killing off the 
old ones? It may come down to me not fully understanding the scale of 
when you say updating configuration, but it may be desirable to not 
scale down your capacity while the update is executing and instead 
having a quick changeover (for instance, in the floating IPs or a load 
balancer).

>> I then feel that using (abusing?) depends_on for update pattern is a bit weird. Maybe I'm influenced by the CFN design, but the separate UpdatePolicy attribute feels better (although I would probably use a property). I guess my main question is around the meaning of using the update pattern on a server instance. I think I see what you want to do for the group, where child_updating would return a number, but I have no idea what it means for a single resource. Could you detail the operation a bit more in the document?
>>
>
> I would be o-k with adding another keyword. The idea in abusing depends_on
> is that it changes the core language less. Properties is definitely out
> for the reasons Christopher brought up, properties is really meant to
> be for the resource's end target only.

I think depends_on would be a clever use of the existing language if we 
weren't in a position to influence it's evolution. A resource's update 
policy is a first-class concept IMO, so adding that notion directly into 
the definition feels cleaner.

[snip]



More information about the OpenStack-dev mailing list