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

Thomas Spatzier thomas.spatzier at de.ibm.com
Tue Feb 4 09:07:18 UTC 2014


Thomas Herve <thomas.herve at enovance.com> wrote on 03/02/2014 21:46:05:
> From: Thomas Herve <thomas.herve at enovance.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 03/02/2014 21:52
> Subject: Re: [openstack-dev] [Heat] [TripleO] Rolling updates spec
> re-written. RFC
>
> > So, I wrote the original rolling updates spec about a year ago, and the
> > time has come to get serious about implementation. I went through it
and
> > basically rewrote the entire thing to reflect the knowledge I have
> > gained from a year of working with Heat.
> >
> > Any and all comments are welcome. I intend to start implementation very
> > soon, as this is an important component of the HA story for TripleO:
> >
> > https://wiki.openstack.org/wiki/Heat/Blueprints/RollingUpdates
>
> Hi Clint, thanks for pushing this.
>
> 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?).
>
> 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 also think that the depends_on feels a bit weird. In most use cases
depends_on is more about waiting for some other resource to be ready, but
for rolling updates the resource if more a data container (a policy) only
that is just there - that's at least how I understand it from a user's
perspective. So refering to that resource via a special property would look
more intuitive to me.

That would also be in line with other cases already implemented: an
InstanceGroup that points to its LaunchConfiguration; a SoftwareDeployment
that points to a SoftwareConfiguration.

>
> It also seems that the interface you're creating (child_creating/
> child_updating) is fairly specific to your use case. For autoscaling
> we have a need for more generic notification system, it would be
> nice to find common grounds. Maybe we can invert the relationship?
> Add a "notified_resources" attribute, which would call hooks on the
> "parent" when actions are happening.
>
> Thanks,
>
> --
> Thomas
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




More information about the OpenStack-dev mailing list