Hi Stackers,
tl;dr
-----
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]
details
-------
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:
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L590-L726
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
