[openstack-dev] [nova] Update on resource providers work

Jay Pipes jaypipes at gmail.com
Mon Jun 6 12:26:38 UTC 2016

Hi Stackers,


0) We moved the resource-providers database tables to the API DB in Nova 
instead of the child cell DB

1) We are reverting the patches to Nova that queried the old and new 
inventory/allocation fields and attempted online data migrations for 
inventory information. [1]

2) New strategy is to complete and review the placement REST API and 
have the resource tracker in Nova directly call the placement API 
instead of attempting to have the ComputeNode object try to determine 
whether a compute node's inventory has been migrated by a complicated 
join expression. [5]


After merging a number of patches to Nova that migrated inventory 
information out of the compute_nodes table into the new inventories 
table, we came to the conclusion that the inventories table needed to be 
in the API database instead of the child cell DB. Our original plan was 
to have the ComputeNode Nova object handle data migrations, however 
after some bugs popped up and extensive back and forth on the 
generic-resource-pools spec, we decided to change directions.

For a transition period, the resource tracker will continue setting the 
legacy inventory fields (e.g. memory_mb) on its stored ComputeNode 
object and calling ComputeNode.save() which will continue to store that 
inventory information in the child cell's DB. In addition to setting 
those legacy inventory fields via the ComputeNode Nova object, the 
resource tracker will call the new placement REST API to store inventory 
and allocation information. This will populate the inventories databas 
tables (now residing in the API database). We will do the same for the 
allocation information (e.g. how much memory an instance used on the 
host): continue to have the resource-tracker store allocation 
information in the legacy locations (e.g. 
instance_extra.flavor.memory_mb) and additionally call a placement REST 
API method to update the allocations database table in the API database.

After discussions, we determined it would be easier to make progress on 
the resource-providers work if we reverted [1] the patches that migrated 
inventory information online in the ComputeNode object. Part of the code 
joined the old compute_nodes table with the new inventories and 
allocations tables (that are now moved to the API database). Clearly, 
joining across two database instances wasn't going to work, so we needed 
to revert the code that changed the nova.db.api.compute_node_get() calls 
to join to both the inventories and allocations tables.

The plan for this and next week is to focus on getting the InventoryList 
and AllocationList object definition patches [2] merged. The 
InventoryList and AllocationList objects will be used by the placement 
API service to retrieve inventory and usage records from the API 
database and update those records in an atomic (to the resource 
provider) fashion using a compare-and-update strategy.

Once the InventoryList and AllocationList objects are merged, then we 
will focus on reviews of the placement REST API patches [3]. Again, we 
are planning on having the nova-compute resource tracker call these REST 
API calls directly (while continuing to use the Nova ComputeNode object 
for saving legacy inventory information). Clearly, before the resource 
tracker can call this placement REST API, we need the placement REST API 
service to be created and a client for it added to OSC. Once this client 
exists, we can add code to the resource tracker which uses it.

And all of the above needs to occur before we even start discussing 
dynamic resource classes [4] or further complications to the resource 
tracking in Nova.

[1] https://review.openstack.org/#/c/325436/
[2] Inventory: https://review.openstack.org/315288
     Allocation: https://review.openstack.org/282442
[3] placement REST API: https://review.openstack.org/#/c/293104/
[4] https://review.openstack.org/#/c/312696/
[5] This is what we came up with originally to return information to the 
ComputeNode object that it could use in determining if the inventory for 
a compute node had been migrated to the new resource-providers 
inventories table: 

More information about the OpenStack-dev mailing list