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

This adds more detail to the spec.

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

Change-Id: I2f701b3d182b331e8533c9d10073d95f1a019ccd

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

@@ -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,
+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
 ---------
@@ -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
+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
     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
+  * 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
     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
 ---------------------
 
-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