Add resource provider allocation unset example to troubleshooting doc

Now that the openstack resource provider allocation unset command is
available [1] this change adds a note about using it in the troubleshooting
doc for cleaning up orphaned allocations.

Sub-sections are used to try and separate the two non-heal_allocations
solutions with the recommended solution first (using the new unset command).

While in here I noticed a typo in the heal_allocations section as well and
fixed it.

[1] I627bfd1ff699d075028da6afafbe7fb9b2f13058

Change-Id: I896bb68c4bdd35d051ef3e95e19bdeb472f9bc99
Related-Bug: #1829479
This commit is contained in:
Matt Riedemann 2019-11-28 09:18:21 -05:00 committed by Stephen Finucane
parent 4c8f3990c6
commit 6c704cc1c5
1 changed files with 25 additions and 12 deletions

View File

@ -91,19 +91,30 @@ Solution
--------
Using the example resources above, remove the allocation for server *vm1* from
the *devstack1* resource provider.
the *devstack1* resource provider. If you have `osc-placement
<https://pypi.org/project/osc-placement/>`_ 1.8.0 or newer, you can use the
:command:`openstack resource provider allocation unset` command to remove the
allocations for consumer *vm1* from resource provider *devstack1*:
Note that we do not use :command:`openstack resource provider allocation delete`
here because that will remove the allocations for the server from all resource
providers, including *devstack2* where it is now running. So we use
.. code-block:: console
$ openstack --os-placement-api-version 1.12 resource provider allocation \
unset --provider $devstack1 $vm1
+--------------------------------------+------------+------------------------------------------------+----------------------------------+----------------------------------+
| resource_provider | generation | resources | project_id | user_id |
+--------------------------------------+------------+------------------------------------------------+----------------------------------+----------------------------------+
| 52d0182d-d466-4210-8f0d-29466bb54feb | 4 | {u'VCPU': 1, u'MEMORY_MB': 512, u'DISK_GB': 1} | 2f3bffc5db2b47deb40808a4ed2d7c7a | 2206168427c54d92ae2b2572bb0da9af |
+--------------------------------------+------------+------------------------------------------------+----------------------------------+----------------------------------+
If you have *osc-placement* 1.7.x or older, the ``unset`` command is not
available and you must instead overwrite the allocations. Note that we do not
use :command:`openstack resource provider allocation delete` here because that
will remove the allocations for the server from all resource providers,
including *devstack2* where it is now running; instead, we use
:command:`openstack resource provider allocation set` to overwrite the
allocations and only retain the *devstack2* provider allocations. If you do
remove all allocations for a given server, you can heal them later. See
`Using heal_allocations`_ for details.
.. TODO: Update this when openstack resource provider allocation set has a
--no-provider option to remove a specific provider from the allocations,
see https://storyboard.openstack.org/#!/story/2006779.
remove all allocations for a given server, you can heal them later. See `Using
heal_allocations`_ for details.
.. code-block:: console
@ -119,7 +130,9 @@ remove all allocations for a given server, you can heal them later. See
| 52d0182d-d466-4210-8f0d-29466bb54feb | 4 | {u'VCPU': 1, u'MEMORY_MB': 512, u'DISK_GB': 1} | 2f3bffc5db2b47deb40808a4ed2d7c7a | 2206168427c54d92ae2b2572bb0da9af |
+--------------------------------------+------------+------------------------------------------------+----------------------------------+----------------------------------+
Now the *devstack1* resource provider can be deleted:
Once the *devstack1* resource provider allocations have been removed using
either of the approaches above, the *devstack1* resource provider can be
deleted:
.. code-block:: console
@ -161,7 +174,7 @@ heal the allocations for the consumer using the
+--------------------------------------+------------+------------------------------------------------+
Note that deleting allocations and then relying on ``heal_allocations`` may not
always the best solution since healing allocations does not account for some
always be the best solution since healing allocations does not account for some
things:
* `Migration-based allocations`_ would be lost if manually deleted during a