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