[chef] Re: Re: Restarting services between recipes


Chronological Thread 
  • From: Russell Bateman < >
  • To:
  • Subject: [chef] Re: Re: Restarting services between recipes
  • Date: Mon, 23 Sep 2013 10:48:51 -0600

I also now see this in other recipes. I must have overlooked its significance.

Many thanks, Steven!

Russ


On 9/22/2013 2:27 AM, Steven De Coeyer wrote:
" type="cite"> Hi Russ

Not sure if I understand the question, but if you want chef to restart service[IP address/DNS name] before it starts running the next recipe, you should add ':immediately' to it like this:
notifies :restart, 'service[IP address/DNS name]', :immediately

If you do not, it might delay the restart until the end of the run (and thus after running the second recipe).
The reason for this is simple: imagine you're placing 100 configuration files and each of them need to restart the same service. You wouldn't want your service to restart a 100 times, but just delay the restart until the end of the run (and only do it once).

Hope that makes sense!

Kind regards,
Steven

On 20 Sep 2013, at 19:19, Russell Bateman < "> > wrote:

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.

§