[openstack-dev] [TripleO] [Puppet] Package updates strategy

James Slagle james.slagle at gmail.com
Thu May 28 15:32:44 UTC 2015


On Thu, May 28, 2015 at 5:02 AM, Martin Mágr <mmagr at redhat.com> 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: OpenStack-dev-request at lists.openstack.org?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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
-- James Slagle
--



More information about the OpenStack-dev mailing list