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
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…
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:
notifies :restart, "service[ IP address/DNS name ]"
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
service IP address/DNS name do
action [ :enable, :start ]
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