Open Stack

On 8/10/15 3:11 PM, Ken Thomas wrote:
> Hi all,
Hey Ken! (we miss you at our IRC meetings :) )
>
> (I've been away for a couple of weeks and I tried to send this before
> I left. I didn't see it come through so my apologies if this is the
> second time you've seen this.)
Nope, this is the first time I've seen this, the [chef] tag isn't used
much so it's nice to see traffic.
>
> I recall markvan mentioning a while ago that there was a need
> for services to restart when the underlying package changed but the
> config file didn't.  We've got something in place and working that
> does exactly that. I'd like to get y'all's opinion if it's an ugly
> kludge or something useful that we might want to refine and contribute
> back.
>
> The basic approach is to look up a given package's version at
> recipe compile time, and then again at runtime.  If the two values are
> different, then we notify the service to stop. We rely on the main
> recipe to make sure that the service is started. This avoids multiple
> restarts if both the package and the config change.
>
> For example, we have a library module that contains a routine
> that does the equivalent of 'rpm -q a <name>'.  If the package isn't
> installed yet, then the library routine will just return an empty
> string and that'll be different from the post install version.
>
> In the recipe itself, we then have the following: (This is from
> our glance recipe.)
>
> # Get access to the library routine that can look up package
> # versions. Note that we're including it twice. The first time is
> # so that we can get the preinstall version during the compile phase.
> # The second include is so that we can check the package version
> # during the run-time phase. Yes, we could have done the preinstall check
> # at run time and just had one include, but that rubyblock of code is
> # more complicated than doing the include.
> class ::Chef::Recipe # rubocop:disable
> Documentation,ClassAndModuleChildren
>   include <our special module>
> end
>
> class ::Chef # rubocop:disable ClassAndModuleChildren
>   class Resource
>     class RubyBlock # rubocop:disable Documentation
>       include <our special module>
>     end
>   end
> end
> ...
> <package install commands>
> ...
> # trigger_pkg is the package that we want to check and was picked it up
> # from an attribute. We'll call our library routine (this is at compile
> # time) and stash the preinstall version.
> node.default['openstack']['image']['preinstall'] =
>   pkg_version(trigger_pkg)
>
> # Check the installed version at runtime, after the pkg commands
> # have actually run.  If there's a change in the version, then tell
> # glance to shutdown. It'll get restarted later on and pick up the
> # new binaries.
> ruby_block 'glance postinstall' do
>   block do
>     postinstall_version = pkg_version(trigger_pkg)
>     preinstall_version = node['openstack']['image']['preinstall']
>     Chef::Log.info "preinstall version: #{preinstall_version}"
>     Chef::Log.info "postinstall version:#{postinstall_version}"
>     if preinstall_version != postinstall_version
>       Chef::Log.info 'Stopping glance services'
>       resources(service: 'glance-api').run_action(:stop)
>       resources(service: 'glance-registry').run_action(:stop)
>     else
>       Chef::Log.info 'No need to stop glance services'
>     end
>   end
> end
>
>
> That's the basics. Is this worth pursuing? If it seems reasonable
> then I'll be happy to write up a spec, including any suggestions y'all
> may have. I.e. there may be some really braindead stuff in there just
> from my ignorance and flailing around just to make it work. I'm
> definitely open to suggestions.
It's an interesting use case, that's for sure. I think a spec around
this, and have a chance for us to talk it out would probably be
advantageous to say the least. I see the advantage of this I really do,
but we've been taking on IRC and it seems that we're gonna try to
simplify our cookbooks for this next cycle, our cookbooks have just
become so complex that we're worried we're scaring people off.

Anyway, lets start with a spec and move from there. Thanks!


Best Regards, 
JJ Asghar 
c: 512.619.0722 t: @jjasghar irc: j^2 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150811/bcdf290f/attachment.html>