nova/releasenotes/notes/quota-usage-placement-5b3f6...

50 lines
2.8 KiB
YAML

upgrade:
- |
It is now possible to count quota usage for cores and ram from the
placement service and instances from instance mappings in the API database
instead of counting resources from cell databases. This makes quota usage
counting resilient in the presence of down or poor-performing cells.
Quota usage counting from placement is opt-in via the
``[quota]count_usage_from_placement`` configuration option.
There are some things to note when opting in to counting quota usage from
placement:
* Counted usage will not be accurate in an environment where multiple Nova
deployments are sharing a placement deployment because currently
placement has no way of partitioning resource providers between different
Nova deployments. Operators who are running multiple Nova deployments
that share a placement deployment should not set the
``[quota]count_usage_from_placement`` configuration option to ``True``.
* Behavior will be different for resizes. During a resize, resource
allocations are held on both the source and destination (even on the same
host, see https://bugs.launchpad.net/nova/+bug/1790204) until the resize
is confirmed or reverted. Quota usage will be inflated for servers in
the ``VERIFY_RESIZE`` state and operators should weigh the advantages and
disadvantages before enabling ``[quota]count_usage_from_placement``.
* The ``populate_queued_for_delete`` and ``populate_user_id`` online data
migrations must be completed before usage can be counted from placement.
Until the data migration is complete, the system will fall back to legacy
quota usage counting from cell databases depending on the result of an
``EXISTS`` database query during each quota check, if
``[quota]count_usage_from_placement`` is set to ``True``. Operators who
want to avoid the performance hit from the ``EXISTS`` queries should wait
to set the ``[quota]count_usage_from_placement`` configuration option to
``True`` until after they have completed their online data migrations via
``nova-manage db online_data_migrations``.
* Behavior will be different for unscheduled servers in ``ERROR`` state.
A server in ``ERROR`` state that has never been scheduled to a compute
host will not have placement allocations, so it will not consume quota
usage for cores and ram.
* Behavior will be different for servers in ``SHELVED_OFFLOADED`` state.
A server in ``SHELVED_OFFLOADED`` state will not have placement
allocations, so it will not consume quota usage for cores and ram. Note
that because of this, it will be possible for a request to unshelve a
server to be rejected if the user does not have enough quota available to
support the cores and ram needed by the server to be unshelved.