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 serverIn 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 ... 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 doThis 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.