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

Martin Mágr mmagr at redhat.com
Fri May 29 12:51:13 UTC 2015


On 05/28/2015 05:32 PM, James Slagle wrote:
>> 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).

Hmpf, it won't solve the library update problem. I didn't think about 
such case.

>
> 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.

Service restart is not triggered by package providers, but by 
dependencies stated in modules.
So using dummy package provider does not seem ideal for me.

>
> 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.
>
Each module would need to have parameter implemented to enable such 
behaviour. But anyway
I don't like this solution because I see it as dirty hack. AFAIR all 
service resources in OpenStack modules
are defined as 'refreshonly'. This means that we could implement in 
Tripleo manifests a logic just
to schedule refresh on them when it is required. Thoughts?

Regards,
Martin




More information about the OpenStack-dev mailing list