Update deprecated NovaCompute parameter names

Some docs examples refer to the now deprecated NovaCompute* parameters,
so update to the new Compute* convention which is consistent with other
roles, and note the correct steps for map parameters (which are merged so
we don't want any old values left in the environment).

Change-Id: I13c75d06c482aa87bac4bab9347dd2ae643af44f

doc/source/install/advanced_deployment/node_config.rst

@@ -17,13 +17,13 @@ Making configuration changes
 If you want to make a configuration change, either prior to initial deployment,
 or subsequently via an update, you can pass additional data to puppet via hiera
 data, using either the global "ExtraConfig" parameter, or one of the role-specific
-parameters, e.g using `NovaComputeExtraConfig` to set the reserved_host_memory
+parameters, e.g using `ComputeExtraConfig` to set the reserved_host_memory
 value for compute nodes::
 
 
     cat > compute_params.yaml << EOF
     parameter_defaults:
-        NovaComputeExtraConfig:
+        ComputeExtraConfig:
           nova::compute::reserved_host_memory: some_value
     EOF
 
@@ -32,12 +32,15 @@ value for compute nodes::
 The parameters available are:
 
   * `ExtraConfig`: Apply the data to all nodes, e.g all roles
-  * `NovaComputeExtraConfig`: Apply the data only to Compute nodes
+  * `ComputeExtraConfig`: Apply the data only to Compute nodes
   * `ControllerExtraConfig`: Apply the data only to Controller nodes
   * `BlockStorageExtraConfig`: Apply the data only to BlockStorage nodes
   * `ObjectStorageExtraConfig`: Apply the data only to ObjectStorage nodes
   * `CephStorageExtraConfig`: Apply the data only to CephStorage nodes
 
+For any custom roles (defined via roles_data.yaml) the parameter name will
+be RoleNameExtraConfig where RoleName is the name specified in roles_data.yaml.
+
 .. note::
 
     Previously the parameter for Controller nodes was named
@@ -47,7 +50,9 @@ The parameters available are:
     passed to `ControllerExtraConfig` instead, and
     `controllerExtraConfig: {}` should be explicitly set in
     `parameter_defaults`, to ensure that values from the old parameter
-    will not be used anymore.
+    will not be used anymore.  Also ComputeExtraConfig was previously
+    named NovaComputeExtraConfig, so a similar update should be performed
+    where the old naming is used.
 
 .. note::
 
@@ -62,7 +67,7 @@ The parameters available are:
     if you want to change the Max IOPS per host setting::
 
        parameter_defaults:
-         NovaComputeExtraConfig:
+         ComputeExtraConfig:
            'nova::scheduler::filter::max_io_ops_per_host': '4.0'
            compute_classes:
            - '::nova::scheduler::filter'

doc/source/install/advanced_deployment/node_placement.rst

@@ -52,11 +52,25 @@ deploy command.
 The same approach is possible for each role via these parameters:
 
   * ControllerSchedulerHints
-  * NovaComputeSchedulerHints
+  * ComputeSchedulerHints
   * BlockStorageSchedulerHints
   * ObjectStorageSchedulerHints
   * CephStorageSchedulerHints
 
+For custom roles (defined via roles_data.yaml) the parameter will be named
+RoleNameSchedulerHints, where RoleName is the name specified in roles_data.yaml.
+
+.. note::
+
+    Previously the parameter for Compute nodes was named
+    `NovaComputeSchedulerHints`. If
+    you are updating a deployment which used the old parameter, all
+    values previously passed to `NovaComputeSchedulerHints` should be
+    passed to `ComputeSchedulerHints` instead, and
+    `NovaComputeSchedulerHints: {}` should be explicitly set in
+    `parameter_defaults`, to ensure that values from the old parameter
+    will not be used anymore.
+
 Custom Hostnames
 ----------------
 
@@ -108,7 +122,7 @@ from the environment file.
 
 The second section is parameter_defaults, where the actual IP addresses are
 assigned.  Each node type has an associated parameter - ControllerIPs for
-controller nodes, NovaComputeIPs for compute nodes, etc.  Each parameter is
+Controller nodes, ComputeIPs for Compute nodes, etc.  Each parameter is
 a map of network names to a list of addresses.  Each network type must have
 at least as many addresses as there will be nodes on that network.  The
 addresses will be assigned in order, so the first node of each type will get