summaryrefslogtreecommitdiff
path: root/releasenotes/notes/quota-usage-placement-5b3f62e83056f59d.yaml
blob: 4e48c099e57c5c5d79ab26f67b07f38253be6f96 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
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.