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 [[email protected]] 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
