Bug 1263055

Description of problem:

The following feedback items were provided during review of the Bare Metal Provisioning document. The items should be considered and applied, where appropriate, to the documentation. Items are divided according to section.

Preface
* One instance of 'Enteprise'

1.2. Subscribe to the Required Channels                                 
* "If you are installing Bare Metal Provisioning on the compute node, your server may already be appropriately subscribed."
  - Perhaps 'a' compute node, because a compute node is really a hypervisor, and there are likely many in a given environment.
  - Also, how can I tell if my machine is already appropriately subscribed? Will a 'yum repolist' cut it?

1.3 Install the Bare Metal Provisioning Packages
* One instance of 'decomissioning' instead of 'decommissioning'

1.7. Configure the Firewall to Allow Bare Metal Provisioning Traffic
* Do we also need to open ports for dependent services such as TFTP, or is everything routed through the ironic service?

1.9. Configure Bare Metal Provisioning to Communicate with OpenStack Networking and OpenStack Image
* Why?

1.10. Configure OpenStack Compute to Use Bare Metal Provisioning
* This sounds important, but what is the outcome of this procedure? Can I still spin up VMs if I change the driver, or does this re-route requests to the ironic driver?

1.12. Configure Bare Metal Provisioning for Cleaning
* I wonder if this is more on the side of additional configuration than initial setup - what do you think? Also, do we know what 'cleaning' does? Does it wipe the bits and pieces on the machine in question, and is this operation somehow visible to users via a status of some kind? If it takes a while, does this mean users can't use some nodes until they come back up?

Chapter 2. Configure Bare Metal Deployment
* Assuming I am a first-time reader, is this a chapter provided as a reference for tuning the service, or do I need to do all this to get it working?

2.2. Create and Upload Images
* In step 3, we set some sensitive environment variables - can we add a step at the end of the procedure or after they are no longer needed to unset them so that clever readers don't scrape our machine's memory to grab these?

2.3. Create the Bare Metal Provisioning Flavor
* I am very curious to know how or whether Ironic divides up nodes in the same group when different flavors are available. This may be beyond the scope of this document if users don't need to do anything, but I wonder how ironic schedules an instance on a node.

2.5. Enroll Hardware with Bare Metal Provisioning
* When we say 'hardware', does this refer to physical machines that will be used to host instances?
* "Compute is not immediately notified of new resources, because Compute’s resource tracker syncs periodically."
  - This is more of a nice-to-have, but how periodically? Sounds almost like something I can set in nova.conf, but if not, are we talking once an hour, or once a minute?

2.6. Configure Local Boot
* "Configure nodes deployed with Bare Metal Provisioning to boot from a local boot loader installed on the disk."
  - Which disk? This sounds like it is just telling the instance we provisioned to boot from disk instead of booting over PXE. Also, this is a great procedure to have, but it also sounds a bit like the node cleaning procedure - additional, optional configuration we can perform to tweak operation.

2.5.1 Enroll a Node with Hardware Introspection
* One instance of 'instrospection' instead of 'introspection'