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.