openstack/nova-specs
Code Issues Proposed changes

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

Browse Source 
This adds more detail to the spec.

Related to blueprint cells-count-resources-to-check-quota-in-api

Change-Id: I2f701b3d182b331e8533c9d10073d95f1a019ccd
This commit is contained in:
melanie witt
2016-11-18 19:21:59 +00:00
committed by Matt Riedemann
parent 9e5358d688
commit 5f2583e827
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 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 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 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. 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 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 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 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, database for the quota commit if the current quota model is kept. If we instead
we can reduce [*]_ the need for compute cells to write to the API database. count resources in the API to check quota, it will be possible in the future
At least, we will eliminate the situation where a quota reserve/commit is split [*]_ to decouple compute cells from the API cell completely.
across the API cell and compute cells.
.. [*] Quota reads and writes cannot be completely eliminated in compute cells .. [*] Quota reads cannot be completely eliminated in compute cells in a
in a special case: nova-compute de/allocating fixed IPs from special case: nova-compute de/allocating fixed IPs from nova-network
nova-network during de/provisioning. This special case can be removed during de/provisioning. Nova-network will need to read quota limits from
when nova-network is fully removed. the API database to check quota. This special case can be removed when
nova-network is fully removed.
Use Cases Use Cases
--------- ---------
@@ -60,7 +60,9 @@ Proposed change
Consumed resources will be counted to check quota instead of the current Consumed resources will be counted to check quota instead of the current
reserve/commit/rollback model. 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" * "Reserve" calls will be replaced with something like "check_resource_count"
which will query the databases for consumed resources, count them, and raise 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 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 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 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 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, 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 Impact
------------------ ------------------
Performance will be adversely affected in the case of counting resources such 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 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 stored in the allocations records at present. In the absence of an efficient
to query the placement API once it has more data and we can do an efficient method through the placement API, to count cores and ram, the following
query through it. Until then, to count cores and ram, the following approach approach is required:
is required:
* Get all instances by project per cell, parsing the flavor JSON blobs and * Get all instances by project per cell, parsing the flavor JSON blobs and
adding up the counts. For example:: adding up the counts. For example::
@@ -123,38 +125,61 @@ is required:
instance_get_all_by_filters(filters={'project_id': myproj}, instance_get_all_by_filters(filters={'project_id': myproj},
expected_attrs=['flavor']) 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: 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 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. 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 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. 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 * floating_ips (ReservableResource): Deprecated in 2.36 and not checked in
is checked when auto_assign_floating_ip allocates a floating ip with 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 nova-network. floating_ips are in the cell database so this would be a
local DB read until nova-network is removed. local DB read until nova-network is removed.
* fixed_ips: not checked in Nova with Neutron. This is checked when * fixed_ips (ReservableResource): Not checked in Nova with Neutron.
nova-compute de/allocates a fixed_ip with nova-network. fixed_ips are in This is checked when nova-compute de/allocates a fixed_ip with
the cell database so this would be a local DB read until nova-network is nova-network. fixed_ips are in the cell database so this would be a local
removed. DB read until nova-network is removed.
* metadata_items: this is a limit on allowed number of image metadata items * metadata_items (AbsoluteResource): This is a limit on allowed number of
and is checked when image metadata requests come in. No counting of image metadata items and is checked when image metadata requests come in.
resources is necessary. No counting of resources in the database is necessary.
* injected_files: Similar to metadata_items. * injected_files (AbsoluteResource): Similar to metadata_items.
* injected_file_content_bytes: Similar to metadata_items. * injected_file_content_bytes (AbsoluteResource): Similar to metadata_items.
* injected_file_path_bytes: Similar to metadata_items. * injected_file_path_bytes (AbsoluteResource): Similar to metadata_items.
* security_group_rules: Similar to security_groups. * security_group_rules (CountableResource): Similar to security_groups.
* key_pairs: this can be obtained from key_pairs table in API DB. * key_pairs (CountableResource): This can be obtained from key_pairs table in
* server_groups: this can be obtained from instance_groups table in API DB. API DB.
* server_group_members: this can be obtained from instance_group_member table * server_groups (ReservableResource): This can be obtained from
in API DB. 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 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 Developer impact
---------------- ----------------
@@ -218,7 +243,7 @@ None
References References
========== ==========
None * https://etherpad.openstack.org/p/ocata-nova-summit-cellsv2-quotas
History History
@@ -227,5 +252,7 @@ History
.. list-table:: Revisions .. list-table:: Revisions
:header-rows: 1 :header-rows: 1
* - Release Name
- Description
* - Ocata * - Ocata
- Introduced - Introduced