Restarting services between recipes

Chef Infra (archive)
1

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

  1. 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

2

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 russ@windofkeltia.com 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

  1. 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

3

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:

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 <russ@windofkeltia.com
mailto:russ@windofkeltia.com> 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

  1. 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