Disabling updates to certain nodes
==================================

Server blacklist
----------------
Servers can be excluded from getting any updated Heat deployments by adding
them to a blacklist parameter called ``DeploymentServerBlacklist``.


Setting the blacklist
_____________________
The ``DeploymentServerBlacklist`` parameter is a list of Heat server names.

Write a new environment file, or add the parameter value to an existing
custom environment file and pass the file to the deployment command::

  parameter_defaults:
    DeploymentServerBlacklist:
      - overcloud-compute-0
      - overcloud-compute-1
      - overcloud-compute-2

.. note::
  The server names in the parameter value are the names according to Heat, not
  the actual server hostnames.

Any servers in the list will be blacklisted by Heat from getting any updated
triggered deployments from Heat. After the stack operation completes, any
blacklisted servers will be unchanged. The blacklisted servers also could have
been powered off, or had their ``os-collect-config`` agents stopped during the
stack operation.

The blacklist can be used during scale out operations or for isolating changes
to certain servers only.

.. warning::
  Blacklisting servers disables **all** updates to the blacklisted nodes, even
  for those deployments that could be considered critical.

.. warning::
  Blacklisting servers should be done with caution, and only when the operator
  understands that the requested change can be applied with a blacklist in
  effect.

  It would be possible to blacklist servers in ways to create a hung stack in
  Heat, or a misconfigured overcloud. For example, cluster configuration
  changes that would need to be applied to all members of a pacemaker cluster
  would not support blacklisting certain cluster members since it
  could result is a misconfigured cluster.

.. warning::
  The blacklist should not be used during the update or upgrade procedures.
  Those procedures have their own methods for isolating changes to particular
  servers. See the documentation for updates/upgrades for more information.

.. warning::
  In cases where servers are added to the blacklist, further changes to those
  nodes are not supported until the server is removed from the blacklist. This
  includes updates/upgrades/scale up/scale down/node replacement.

Clearing the blacklist
______________________
When clearing the blacklist for subsequent stack operations, an empty parameter
value must be sent with the deploy command. It is not sufficient to simply omit
the parameter since Heat will use the previously saved value.

Send an empty list value to force Heat to clear the blacklist::

  parameter_defaults:
    DeploymentServerBlacklist: []

Skip deploy identifier
----------------------
The default behavior during a stack update operation is to force puppet to
reapply all manifests. This can be a time consuming operation and is not always
required if not changing any configuration date such as in the case of only
scaling out certain roles.

The beavhior can be overridden by passing ``--skip-deploy-identifier`` to the
``openstack overcloud deploy`` command.

Similar to the server blacklist feature, this feature should be used only when
the operator is sure that puppet can be safely skipped on the stack update.

.. note::
  In some cases, puppet will still run even when ``--skip-deploy-identifier``
  is specified. These cases include changes to puppet manifests or hieradata.