Open Stack

my gut feeling is that it will take way more work to do this well, then to dockerize the various parts, and then puppet (or whatever) could simply stop/start containers that had a new version. It could easily pick up what needed updating then. It would also fix once and for all the issue of wanting to run release X service A with release X+1 service B on the same controller. So using the same process to upgrade from one release to another, while still hard, would potentially be doable with the process, if done very carefully.

I don't think it would be difficult to make some very basic containers where the config is passed through as a volume managed by puppet? Most of the existing code would still work then?

Thanks,
Kevin
________________________________________
From: Zane Bitter [zbitter at redhat.com]
Sent: Wednesday, May 27, 2015 3:49 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [TripleO] Package updates strategy

Steve is working on a patch to allow package-based updates of overcloud
nodes[1] using the distro's package manager (yum in the case of RDO, but
conceivable apt in others). Note we're talking exclusively about minor
updates, not version-to-version upgrades here.

Dan mentioned at the summit that this approach fails to take into
account the complex ballet of service restarts required to update
OpenStack services. (/me shakes fist at OpenStack services.) And
furthermore, that the Puppet manifests already encode the necessary
relationships to do this properly. (Thanks Puppeteers!) Indeed we'd be
doing the Wrong Thing by Puppet if we changed this stuff from under it.

The problem of course is that neither Puppet nor yum/apt has a view of
the entire system. Yum doesn't know about the relationships between
services and Puppet doesn't know about all of the _other_ packages that
they depend on.

One solution proposed was to do a yum update first but specifically
exclude any packages that Puppet knows about (the --excludes flag
appears sufficient for this); then follow that up with another Puppet
run using ensure -> latest.

A problem with that approach is that it still fails to restart services
which have had libraries updated but have not themselves been updated.
That's no worse than the pure yum approach though. We might need an
additional way to just manually trigger a restart of services.

What do folks think of this plan? Anybody got better ideas?

thanks,
Zane.

[1] https://review.openstack.org/#/c/179974

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev