blob: 9a295f2e16a8ca7ef6810757700b79878e2a1181 (
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
|
---
other:
- |
This release includes work in progress support for Keystone's unified
limits. This should not be used in production. It is included so we can
collect early feedback from operators around the performance of the new
limits system. There is currently no way to export your existing quotas
and import them into Keystone. There is also no proxy API to allow you
to update unified limits via Nova APIs. All the update APIs behave as if
you are using the noop driver when the unified limits quota driver is
configured.
When you enable unified limits, those are configured in Keystone against
the Nova endpoint, using the names:
* ``class:VCPU``
* ``servers``
* ``class:MEMORY_MB``
* ``server_metadata_items``
* ``server_injected_files``
* ``server_injected_file_content_bytes``
* ``server_injected_file_path_bytes``
* ``server_key_pairs``
* ``server_groups``
* ``server_group_members``
All other resources classes requested via flavors are also now supported as
unified limits. Note that nova configuration is ignored, as the default
limits come from the limits registered for the Nova endpoint in Keystone.
All previous quotas other than ``cores``, ``instances`` and ``ram`` are
still enforced, but the limit can only be changed globally in Keystone as
registered limits. There are no per project or per user overrides
possible.
Work in progress support for Keystone's unified limits
can be enabled via ``[quota]/driver=nova.quota.UnifiedLimitsDriver``
A config option ``[workarounds]unified_limits_count_pcpu_as_vcpu`` is
available for operators who require the legacy quota usage behavior where
VCPU = VCPU + PCPU. Note that if ``PCPU`` is specified in the flavor
explicitly, it will be expected to have its own unified limit registered
and PCPU usage will *not* be merged into VCPU usage.
|
