[openstack-dev] [chef] Restart service when package changes but config doesn't
Hi all,
(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.)
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 '. 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
end
class ::Chef # rubocop:disable ClassAndModuleChildren
class Resource
class RubyBlock # rubocop:disable Documentation
include
end
end
end
...
...
# 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.
Ken
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [chef] Restart service when package changes but config doesn't
Hi all,
(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.)
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 '. 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
end
class ::Chef # rubocop:disable ClassAndModuleChildren class Resource class
RubyBlock # rubocop:disable Documentation include
end endend..# 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 endend
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.
Ken__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Chef] Deprecated database settings?
Greetings all, I'm looking at the nova.conf template in the most recent/Juno Chef recipe [1] and I noticed that it's using the deprecated "sql_connection" setting in [DEFAULT] rather than the "connection" setting in the [DATABASE] section [2]. In fact, I don't see any [DATABASE] section at all in nova.conf.erb (or in any other Chef recipes) with the other useful settings like slave_connection, min_pool_size, etc. Am I missing something? If they need to be added, I'll be happy to help out. Thanks, Ken [1] https://github.com/stackforge/cookbook-openstack-compute/blob/master/templates/default/nova.conf.erb[2] https://github.com/openstack/oslo.db/blob/stable/juno/oslo/db/options.py#L36 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Stack stuck in DELETE_IN_PROGRESS even though all resources are DELETE_COMPLETE
Greetings all, I'm using Heat from Icehouse and I'm hitting a problem that I'm hoping y'all can shed some light on. I have no problems doing stack-create. I can watch the MySQL commands go by and see it happily update the stack table so that it eventually shows up as CREATE_COMPLETE. When I delete the stack, everything seems to be working fine. I see the MySQL update that sets the stack to DELETE IN PROGRESS as well as the updates that sets my single resource to DELETE_COMPLETE... but I never see the final update to the stack table to set it to DELETE COMPLETE. One very odd thing that I found in the MySQL logs (snippet below), is a query that includes that stack name but with an extra '*' character append to it. My stack is named 'xyzzy8' but notice the 'xzyzzy8*' in the constraint. That's not going to return anything and I'm wondering if that is what's preventing the final stack DELETE_COMPLTE update from happening? There are no errors in the any of the heat logs. Any guidance would be greatly appreciated! Ken SELECT stack.status_reason AS stack_status_reason, stack.created_at AS stack_created_at, stack.deleted_at AS stack_deleted_at, stack.action AS stack_action, stack.status AS stack_status, stack.id AS stack_id, stack.name AS stack_name, stack.raw_template_id AS stack_raw_template_id, stack.username AS stack_username, stack.tenant AS stack_tenant, stack.parameters AS stack_parameters, stack.user_creds_id AS stack_user_creds_id, stack.owner_id AS stack_owner_id, stack.timeout AS stack_timeout, stack.disable_rollback AS stack_disable_rollback, stack.stack_user_project_id AS stack_stack_user_project_id, stack.updated_at AS stack_updated_atFROM stackWHERE stack.deleted_at IS NULL AND (stack.tenant = 'c6c488223aae4e97bf56dda8cef36b3b' OR stack.stack_user_project_id = 'c6c488223aae4e97bf56dda8cef36b3b') AND stack.name = 'xyzzy8*' AND stack.owner_id = '9a3e56d7-0c10-4c1c-8c54-0e5580cee121' ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
