On Thu, May 28, 2015 at 5:02 AM, Martin Mágr <[email protected]> wrote: > > On 05/28/2015 10:47 AM, Jan Provaznik wrote: >> >> On 05/28/2015 10:25 AM, Martin Mágr wrote: >>> >>> >>> On 05/28/2015 09:35 AM, Jan Provaznik wrote: >>>> >>>> On 05/28/2015 01:10 AM, Steve Baker wrote: >>>>> >>>>> On 28/05/15 10:54, Richard Raseley wrote: >>>>>> >>>>>> Zane Bitter wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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. >>>>>>> >>>>> My only concern with this approach is how do we collect and maintain >>>>> the >>>>> excludes list. Other than that it sounds reasonable. >>>> >>>> >>>> Why not swap the order? First run puppet using ensure=>latest which >>>> updates/restarts everything Openstack depends on, then run yum/apt >>>> update to update any remaining bits. You wouldn't need exclude list >>>> then. >>> >>> >>> Isn't running Puppet with 'ensure => latest' enough? If packaging is >>> correct all dependencies which will require update will be updated >>> together with packages updated by Puppet. Am I missing something or the >>> goal here is to update all packages? >>> >> >> Yes - the goal so to update all packages (so puppet only is not sufficient >> because it will not take care of packages which are not listed in puppet >> modules). >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > Then I'm +1 for running Puppet with 'ensure => latest' first and then 'yum > update -y'. Seems ideal solution from my point of view.
How would this solve the library update problem though?. If a new version of a library is released to address a security issue or what not, first you'd run puppet, which doesn't see anything new. Then the "yum update -y" would pick up the library update, but no services would get restarted. I don't think we can convince all distros to rev every package version that might depend on such a library update. Take something like heartbleed for example, when the updated openssl was released, there wasn't a corresponding rebuild of every package out there that requires openssl to set a minimum requires on the new openssl version (that I know of). I don't know puppet internals at all, but what about some type of Puppet provider that overrides "latest" to make Puppet think that it's actually updated a package even if no such update exists? That could trigger Puppet to then restart the services b/c it thinks it's updated something. SImilar to what TripleO is doing with the norpm provider where the install is a noop: https://github.com/stackforge/puppet-tripleo/blob/master/lib/puppet/provider/package/norpm.rb Could we then swap in this provider when we're triggering the update via Heat? So we do a yum update -y, and then rerun puppet, and it thinks it's updated everything, so it restarts as needed. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- James Slagle -- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
