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]
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
