Merge pull request #141 from miharp/feat/remove-mcollective

Remove MCollective references, replace with Choria

Author: tuxmea

docs/_openvox_8x/services_agent_unix.markdown

@@ -4,7 +4,7 @@ title: "Puppet's services: Puppet agent on *nix systems"
 ---
 
 [resource type reference]: ./type.html
-[MCollective]: /mcollective
+[Choria]: https://choria.io
 [puppet.conf]: ./config_file_main.html
 [runinterval]: ./configuration.html#runinterval
 [onetime]: ./configuration.html#onetime
@@ -69,7 +69,7 @@ On \*nix nodes, there are three main ways to do this:
 
 * **Run Puppet agent as a service.** The easiest method. The Puppet agent daemon does configuration runs at a set interval, which can be configured.
 * **Make a cron job that runs Puppet agent.** Requires more manual configuration, but a good choice if you want to reduce the number of persistent processes on your systems.
-* **Only run Puppet agent on demand.** You can also deploy [MCollective][] to run on demand on many nodes.
+* **Only run Puppet agent on demand.** You can use an orchestration tool such as [Choria][] to trigger runs on demand across many nodes.
 
 Choose whichever one works best for your infrastructure and culture. 
 
@@ -129,15 +129,15 @@ This behavior is good for building a cron job that does configuration runs. You
 
 Some sites prefer to only run Puppet agent on demand; others use scheduled runs, but occasionally need to do an on-demand run.
 
-Puppet agent runs can be started while logged in to the target system, or remotely with MCollective.
+Puppet agent runs can be started while logged in to the target system, or remotely via an orchestration tool.
 
 1. Run Puppet agent on one machine, using ssh:
 
    ``` bash
    ssh ops@magpie.example.com sudo puppet agent --test
    ```
 
-To run remotely on _many_ machines, you need some form of orchestration or parallel execution tool, such as MCollective. MCollective ships as a part of the `puppet-agent` package, but you need to [deploy it](/mcollective/deploy/standard.html) and [the puppet agent plugin](https://github.com/puppetlabs/mcollective-puppet-agent). Once everything is ready, see the instructions in [the puppet agent plugin's README](https://github.com/puppetlabs/mcollective-puppet-agent#readme) for usage details.
+To run remotely on _many_ machines, you need an orchestration tool. [Choria][] is the community-supported successor to MCollective and supports triggering Puppet agent runs across a fleet of nodes.
 
 ## Disable and re-enable Puppet runs
 

docs/_openvox_8x/services_agent_windows.markdown

@@ -6,7 +6,7 @@ title: "Puppet's services: Puppet agent on Windows systems"
 [catalogs]: ./subsystem_catalog_compilation.html
 [unix_agent]: ./services_agent_unix.html
 [resource type reference]: ./type.html
-[mcollective]: /mcollective
+[Choria]: https://choria.io
 [puppet.conf]: ./config_file_main.html
 [runinterval]: ./configuration.html#runinterval
 [short_settings]: ./config_important_settings.html#settings-for-agents-all-nodes
@@ -48,7 +48,7 @@ In a normal Puppet configuration, every node periodically does configuration run
 On Windows nodes, there are two main ways to do this:
 
 * **Run Puppet agent as a service.** The easiest method. The Puppet agent service does configuration runs at a set interval, which can be configured.
-* **Only run Puppet agent on demand.** You can also deploy [MCollective][] to run on demand on many nodes.
+* **Only run Puppet agent on demand.** You can use an orchestration tool such as [Choria][] to trigger runs on demand across many nodes.
 
 Since the Windows version of the Puppet agent service is much simpler than the \*nix version, there's no real performance to be gained by running Puppet as a scheduled task, but if you do want scheduled configuration runs, use the Windows service.
 
@@ -97,7 +97,7 @@ To change the arguments used when triggering a Puppet agent run (this example ch
 
 Some sites prefer to only run Puppet agent on demand; others occasionally need to do an on-demand run.
 
-Puppet agent runs can be started locally while logged in to the target system, or remotely with MCollective.
+Puppet agent runs can be started locally while logged in to the target system, or remotely via an orchestration tool.
 
 #### While logged in to the target system
 
@@ -121,7 +121,7 @@ This prompts it to ask for UAC confirmation:
 
 #### Remotely
 
-Open source Puppet users can install [MCollective][] and [the puppet agent plugin](https://github.com/puppetlabs/mcollective-puppet-agent) to get similar capabilities, but Puppet doesn't provide standalone MCollective packages for Windows.
+[Choria][] is the community-supported successor to MCollective and supports triggering Puppet agent runs across a fleet of nodes, including Windows.
 
 ## Disabling and re-enabling Puppet runs
 

docs/_openvox_8x/ssl_regenerate_certificates.markdown

@@ -8,7 +8,6 @@ description: "This page describes the steps for regenerating certs under an open
 [monolithic]: {{pe}}/trouble_regenerate_certs_monolithic.html
 [puppetdb]: /openvoxdb/latest/
 [puppet dashboard]: /dashboard/1.2
-[mcollective]: /mcollective
 [ssldir]: ./dirs_ssldir.html
 
 > **Note:** If you're visiting this page to remediate your Puppet Enterprise deployment due to [CVE-2014-0160][cve], a.k.a. "Heartbleed," [please see this announcement][blog] for additional information and links to more resources before using this guide. Before applying these instructions, please bear in mind that this is a non-trivial operation that contains some manual steps and will require you to replace certificates on  every agent node managed by your Puppet master.
@@ -53,18 +52,15 @@ Note that this process **destroys the certificate authority and all other certif
 > * You have a brand new CA certificate and key.
 > * Your Puppet master has a certificate from the new CA, and it can once again field new certificate requests.
 > * The Puppet master will reject any requests for configuration catalogs from nodes that haven't replaced their certificates (which, at this point, will be all of them except itself).
-> * If you are using any extensions that rely on Puppet certificates, like PuppetDB or MCollective, the Puppet master won't be able to communicate with them. Consequently, it might not be able to serve catalogs, even to agents that do have new certificates.
+> * If you are using any extensions that rely on Puppet certificates, like PuppetDB, the Puppet master won't be able to communicate with them. Consequently, it might not be able to serve catalogs, even to agents that do have new certificates.
 
 ## Step 2: Clear and regenerate certs for any extensions
 
-You might be using an extension, like PuppetDB or MCollective, to enhance Puppet. These extensions probably use certificates from Puppet's CA in order to communicate securely with the Puppet master.
+You might be using an extension, like PuppetDB, to enhance Puppet. These extensions probably use certificates from Puppet's CA in order to communicate securely with the Puppet master.
 
 For each extension like this, you'll need to regenerate the certificates it uses. Many tools have scripts or documentation to help you set up SSL, and you can often just re-run the setup instructions.
 
 * [PuppetDB][] users should first follow [the instructions below on regenerating agent certificates][agent_certs], since PuppetDB re-uses Puppet agents' certificates. After that, restart the PuppetDB service.
-* [MCollective][] often uses SSL certificates from Puppet's CA. If you are replacing your Puppet CA and are using the same certs for MCollective, you should [go through the standard deployment guide][standard_mco] and re-do any steps involving security credentials. You'll generally need to replace client certificates, your server keypair, and the ActiveMQ server's keystore and truststore.
-
-[standard_mco]: /mcollective/deploy/standard.html
 
 ## Step 3: Clear and regenerate certs for Puppet agents
 

docs/_openvoxdb_8x/scaling_recommendations.markdown

@@ -58,7 +58,7 @@ The more frequently your Puppet nodes check in, the heavier the load on your Pup
 
 You can reduce the need for higher performance by changing the [`runinterval`][runinterval] setting in every Puppet node's puppet.conf file. (Or, if running Puppet agent from cron, by changing the frequency of the cron task.)
 
-The frequency with which nodes should check in will depend on your site's policies and expectations --- this is as much a cultural decision as it is a technical one. A possible compromise is to use a wider default check-in interval, but implement MCollective's `puppetd` plugin to trigger immediate runs when needed.
+The frequency with which nodes should check in will depend on your site's policies and expectations --- this is as much a cultural decision as it is a technical one. A possible compromise is to use a wider default check-in interval, but use an orchestration tool such as [Choria](https://choria.io) to trigger immediate runs when needed.
 
 ## Bottleneck: CPU cores and number of worker threads