[chef] Restarting services between recipes


Chronological Thread 
  • From: Russell Bateman < >
  • To:
  • Subject: [chef] Restarting services between recipes
  • Date: Fri, 20 Sep 2013 11:19:39 -0600

I've Googled for this, but the comments leave me rather confused and there are different flavors (?) of Chef like Vagrant that appear to have different answers.

Before I can use Chef to execute MongoDB shell commands in later recipes that perform specific, crucial operations like initiate a replica set, add an arbiter, add a shard, enable sharding, turn sharding on for a database or collection, etc., I need my MongoDB mongod or mongos instance to come in its final form.

I had first assumed I'd just have to bounce a given node, knife a different definition and roles to it, then re-run chef-client to get this work done, but I figured Chef was way beyond that and I looked for reboot, restart, etc. and found this.

My set-up is simple:
- one host running the Chef server
- n hosts running the Chef client
- no magic stuff like Vagrant, Solo or any other capitalized things I don't know about or understand yet.
In short, I'm writing some recipes to mount my MongoDB cluster. (I'm only interested in Ubuntu in my data center.) Please help me verify that...

1. At the end of one recipe in which I use template to create the MongoDB configuration file(s) that will cause MongoDB to be launched the way I need it, I'll use:
template ...
  .
  .
  .
  notifies :restart, "service[ IP address/DNS name ]"
end

and that

2. Chef will restart MongoDB for the next recipe if I add the following block before the end of my recipe after its finalized the configuration file(s):
service IP address/DNS name do
  provider Chef::Provider::Service::Upstart
action [ :enable, :start ]
end
This looks like sheer hocus-pocus. Is this how it's supposed to work? Will it be able to pick up the very upstart configuration file I just created (which may not be named /etc/init/mongodb.conf in every case)? In certain testing set-ups, I'm going to have an arbiter, configuration server and sharding router running on a single, multipurpose node, so the provider upstart service would have to be pretty intelligent about it.

Thanks for any warnings, caveats, other information and wisdom you can offer.

Russ



Archive powered by MHonArc 2.6.16.

§