openstack/nova-specs
Code Issues Proposed changes

Merge "Amend proposal to count resources to check quota in API for cells"

Browse Source
This commit is contained in:
Jenkins
2016-12-01 14:01:32 +00:00
committed by Gerrit Code Review
parent 15a0da1190 5f2583e827
commit d0a6bcf39d
1 changed files with 64 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

101
specs/ocata/approved/cells-count-resources-to-check-quota-in-api.rst
View File

@@ -20,7 +20,7 @@ need to have the API database connection in their configuration.
We propose a new approach of counting consumed resources and checking the
count against the quota limits in the API instead of the current reserve/commit
model where a reservation record is created, quota usage records are created
and marked as "in_use" when they are committed, and the reservarion record
and marked as "in_use" when they are committed, and the reservation record
deleted.
@@ -37,15 +37,15 @@ to modify the "reserved" field and deletes the reservation record.
For instance delete, resources are first reserved in the API when a request is
received and then the reservation is later committed in compute when the
resources are freed. In cellsv2, this means compute cells will write to the API
database for the quota commit. By counting resources in the API to check quota,
we can reduce [*]_ the need for compute cells to write to the API database.
At least, we will eliminate the situation where a quota reserve/commit is split
across the API cell and compute cells.
database for the quota commit if the current quota model is kept. If we instead
count resources in the API to check quota, it will be possible in the future
[*]_ to decouple compute cells from the API cell completely.
.. [*] Quota reads and writes cannot be completely eliminated in compute cells
in a special case: nova-compute de/allocating fixed IPs from
nova-network during de/provisioning. This special case can be removed
when nova-network is fully removed.
.. [*] Quota reads cannot be completely eliminated in compute cells in a
special case: nova-compute de/allocating fixed IPs from nova-network
during de/provisioning. Nova-network will need to read quota limits from
the API database to check quota. This special case can be removed when
nova-network is fully removed.
Use Cases
---------
@@ -60,7 +60,9 @@ Proposed change
Consumed resources will be counted to check quota instead of the current
reserve/commit/rollback model.
* "Reserve," "commit," and "rollback" calls will be removed everywhere.
* "Reserve," "commit," and "rollback" calls will be removed everywhere. Quota
checks will instead consist of reading the quota limits from the API database
and comparing the limit with the resource count.
* "Reserve" calls will be replaced with something like "check_resource_count"
which will query the databases for consumed resources, count them, and raise
@@ -79,7 +81,8 @@ counting approach, no such update would be needed.
Data model impact
-----------------
None
We could drop the reservations and quota_usages tables from the API database as
they won't be used.
REST API impact
---------------
@@ -105,17 +108,16 @@ of their quota limits. This is because we must aggregate consumed resources
across instances in separate databases. So it would be possible for a quota
check Y to pass at the API and shortly after a racing request X also passed
quota check will have consumed the remaining resources allowed for the project,
and then request Y will consume more resources than the quota afterward.
and then request Y will consume more resources than the quota limit afterward.
Performance Impact
------------------
Performance will be adversely affected in the case of counting resources such
as cores and ram. This is because there is currently no project association
stored in the allocations records at present. In the future, we will be able
to query the placement API once it has more data and we can do an efficient
query through it. Until then, to count cores and ram, the following approach
is required:
stored in the allocations records at present. In the absence of an efficient
method through the placement API, to count cores and ram, the following
approach is required:
* Get all instances by project per cell, parsing the flavor JSON blobs and
adding up the counts. For example::
@@ -123,38 +125,61 @@ is required:
instance_get_all_by_filters(filters={'project_id': myproj},
expected_attrs=['flavor'])
The plan is to work with the placement API subteam to get an efficient call
for resource allocation by project to improve the performance.
All other resources should be able to be counted in one step:
* instances: this can be obtained from instance_mappings table in API DB.
* instances (ReservableResource): This can be obtained from instance_mappings
table in API DB.
We may be able to create a tally from the aforementioned cores/ram query
and use that instead of doing a new query of instance_mappings.
* security_groups: deprecated in 2.36 and not checked in Nova with Neutron.
* security_groups (ReservableResource): Deprecated in 2.36 and not checked in
Nova with Neutron.
This is checked in the API with nova-network. security_groups are in the
cell database so this would be a cell DB read from the API to check.
* floating_ips: deprecated in 2.36 and not checked in Nova with Neutron. This
is checked when auto_assign_floating_ip allocates a floating ip with
* floating_ips (ReservableResource): Deprecated in 2.36 and not checked in
Nova with Neutron.
This is checked when auto_assign_floating_ip allocates a floating ip with
nova-network. floating_ips are in the cell database so this would be a
local DB read until nova-network is removed.
* fixed_ips: not checked in Nova with Neutron. This is checked when
nova-compute de/allocates a fixed_ip with nova-network. fixed_ips are in
the cell database so this would be a local DB read until nova-network is
removed.
* metadata_items: this is a limit on allowed number of image metadata items
and is checked when image metadata requests come in. No counting of
resources is necessary.
* injected_files: Similar to metadata_items.
* injected_file_content_bytes: Similar to metadata_items.
* injected_file_path_bytes: Similar to metadata_items.
* security_group_rules: Similar to security_groups.
* key_pairs: this can be obtained from key_pairs table in API DB.
* server_groups: this can be obtained from instance_groups table in API DB.
* server_group_members: this can be obtained from instance_group_member table
in API DB.
* fixed_ips (ReservableResource): Not checked in Nova with Neutron.
This is checked when nova-compute de/allocates a fixed_ip with
nova-network. fixed_ips are in the cell database so this would be a local
DB read until nova-network is removed.
* metadata_items (AbsoluteResource): This is a limit on allowed number of
image metadata items and is checked when image metadata requests come in.
No counting of resources in the database is necessary.
* injected_files (AbsoluteResource): Similar to metadata_items.
* injected_file_content_bytes (AbsoluteResource): Similar to metadata_items.
* injected_file_path_bytes (AbsoluteResource): Similar to metadata_items.
* security_group_rules (CountableResource): Similar to security_groups.
* key_pairs (CountableResource): This can be obtained from key_pairs table in
API DB.
* server_groups (ReservableResource): This can be obtained from
instance_groups table in API DB.
* server_group_members (CountableResource): This can be obtained from
instance_group_member table in API DB.
Here is an explanation of the resource types, taken from a ML post [1]_:
* ReservableResource: Can be used with reservations, resources are stored in
the DB.
* AbsoluteResource: Number of resources are not stored in the DB.
* CountableResource: Subclass of AbsoluteResource except resources are stored
in the DB. Has a counting function that will be called to determine the
current counts of the resource. Not intended to count by project ID.
With the new approach, it seems like ReservableResources should be changed to
CountableResources with a count function provided for each.
.. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-December/081334.html
Other deployer impact
---------------------
None
The "nova-manage project quota_usage_refresh" command can be deprecated as
refreshing quotas would no longer be something we do.
Developer impact
----------------
@@ -218,7 +243,7 @@ None
References
==========
None
* https://etherpad.openstack.org/p/ocata-nova-summit-cellsv2-quotas
History
@@ -227,5 +252,7 @@ History
.. list-table:: Revisions
:header-rows: 1
* - Release Name
- Description
* - Ocata
- Introduced