openstack
/
tripleo-docs
Code Issues Proposed changes

Add more tags examples to IHA 

This commit adds two additional examples about tags, so now we have
concrete examples for either images, flavors and VMs (otherwise these
commands are really hard to find or imagine).

Change-Id: Ib3c245200129faeb2e38a1cc80e66de6ec698b47
This commit is contained in:
Raoul Scarazzini 2018-04-12 17:53:34 +02:00
parent 7d376e6b09
commit fb47e7db30
1 changed files with 13 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/source/install/advanced_deployment/instance_ha.rst
View File

@ -64,8 +64,18 @@ the following steps are needed:
lanplus: 1
Once the deployment is completed, the overcloud should show a stonith device for each compute node and one for each controller node and a GuestNode for every compute node. The expected behaviour is that if a compute node dies, it will be fenced and the VMs that were running on it will be evacuated (i.e. restarted) on another compute node.
Once the deployment is completed, the overcloud should show a stonith device for each compute node and one for each controller node and a GuestNode for every compute node. The expected behavior is that if a compute node dies, it will be fenced and the VMs that were running on it will be evacuated (i.e. restarted) on another compute node.
In case it is necessary to limit which VMs are to be resuscitated on another compute node, it is possible to either tag the image, the flavor or the VM with the ``evacuable`` tag. For example::
In case it is necessary to limit which VMs are to be resuscitated on another compute node it is possible to tag with ``evacuable`` either the image::
openstack image set --tag evacuable 0c305437-89eb-48bc-9997-e4e4ea77e449
openstack image set --tag evacuable 0c305437-89eb-48bc-9997-e4e4ea77e449
the flavor::
nova flavor-key bb31d84a-72b3-4425-90f7-25fea81e012f set evacuable=true
or the VM::
nova server-tag-add 89b70b07-8199-46f4-9b2d-849e5cdda3c2 evacuable
At the moment this last method should be avoided because of a significant reason: setting the tag on a single VM means that just *that* instance will be evacuated, tagging no VM implies that *all* the servers on the compute node will resuscitate. In a partial tagging situation, if a compute node runs only untagged VMs, the cluster will evacuate all of them, ignoring the overall tag status.