This is placement update 18-27, a weekly update of ongoing development related to the OpenStack placement service. This is a contract version.
Most Important
In the past week or so we've found a two suites of bugs that are holding up other work. One set is related to consumers and the handling of consumer generations (linked in that theme, below). The other is related to various ways in which managing parents of nested providers is not correct. Those are:
The first is already fixed, the second was discovered as a result of thinking about the first.
We also have some open questions about which of consumer id, project id, and user id are definitely going to be a valid UUID and what that means in relation to enforcement and our definition of "what's a good uuid":
As usual, this is more support for the fact that we need to be doing increased manual testing to find where our automated tests have gaps, and fill them.
On themes, we have several things rushing for attention before the end of the cycle (reminder: Feature Freeze is the end of this month). We need to get the various facets of consumers fixed up in a way that we all agree is correct. We need to get the Reshaped Providers implemented. And there's some hope (maybe vain?) that we can get the report client and virt drivers talking in a more nested and shared form.
What's Changed
The microversion for nested allocation candidates has merged as 1.29.
The huge pile of osc-placement changes at https://review.openstack.org/#/q/topic:bp/placement-osc-plugin-rocky has merged. Yay!
Bugs
- Placement related bugs not yet in progress: 16, -3 on last week.
- In progress placement bugs 17, +7 on last week.
Questions
- Will consumer id, project and user id always be a UUID? We've established for certain that user id will not, but things are less clear for the other two. This issue is compounded by the fact that these two strings are different but the same UUID: 5eb033fd-c550-420e-a31c-3ec2703a403c, 5eb033fdc550420ea31c3ec2703a403c (bug 1758057 mentioned above) but we treat them differently in our code.
Main Themes
Documentation
This is a section for reminding us to document all the fun stuff we are enabling. Open areas include:
-
Documenting optional placement database. A bug, 1778227 has been created to track this. This has started, for the install docs, but there are more places that need to be touched.
-
"How to deploy / model shared disk. Seems fairly straight-forward, and we could even maybe create a multi-node ceph job that does this - wouldn't that be awesome?!?!", says an enthusiastic Matt Riedemann.
-
The whens and wheres of re-shaping and VGPUs.
Nested providers in allocation candidates
The main code of this has merged. What's left are dealing with things like the parenting bugs mentioned above, and actually reporting any nested providers and inventory so we can make use of them.
Consumer Generations
A fair bit of open bugs fixes and debate on this stuff.
- https://bugs.launchpad.net/nova/+bug/1779717 No ability to update consumer's project and/or user external ID
- https://bugs.launchpad.net/nova/+bug/1778763 Consumers never get deleted
- https://review.openstack.org/#/c/580373/ Add UUID validation for consumer_uuid (This one has some of the discussion about whether consumers are always going to be UUIDs)
- https://review.openstack.org/#/c/579920/ move lookup of provider from _new_allocations()
- https://review.openstack.org/#/c/579163/ return 404 when no consumer found in allocs
Note that once this is correct we'll still have work to do in the report client to handle consumer generations before nova can do anything with it.
Reshape Provider Trees
This allows moving inventory and allocations that were on resource provider A to resource provider B in an atomic fashion. The blueprint topic is:
There are WIPs for the HTTP parts and the resource tracker parts, on that topic.
Mirror Host Aggregates
This needs a command line tool:
Extraction
Extraction is mostly taking a back seat at the moment while we find and fix bugs in existing features. We've also done quite a lot of the preparatory work. The main things to be thinking about are:
- os-resource-classes
- infra and co-gating issues that are going to come up
- copying whatever nova-based test fixture we might like
Other
24 entries last week. 20 now (this is a contract week, there's plenty of new reviews not listed here).
-
https://review.openstack.org/#/c/546660/ Purge comp_node and res_prvdr records during deletion of cells/hosts
-
https://review.openstack.org/#/c/527791/ Get resource provider by uuid or name (osc-placement)
-
https://review.openstack.org/#/c/556669/ Tighten up ReportClient use of generation
-
https://review.openstack.org/#/c/537614/ Add unit test for non-placement resize
-
https://review.openstack.org/#/c/535517/ Move refresh time from report client to prov tree
-
https://review.openstack.org/#/c/561770/ PCPU resource class
-
https://review.openstack.org/#/c/566166/ rework how we pass candidate request information
-
https://review.openstack.org/#/c/564876/ add root parent NULL online migration
-
https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider add resource_requests field to RequestSpec
-
https://review.openstack.org/#/c/538498/ Convert driver supported capabilities to compute node provider traits
-
https://review.openstack.org/#/c/568639/ Use placement.inventory.inuse in report client
-
https://review.openstack.org/#/c/517921/ ironic: Report resources as reserved when needed
-
https://review.openstack.org/#/c/568713/ Test for multiple limit/group_policy qparams
-
https://review.openstack.org/#/c/578048/ [placement] api-ref: add traits parameter
-
https://review.openstack.org/#/c/578826/ Convert 'placement_api_docs' into a Sphinx extension
-
https://review.openstack.org/#/c/568713/ Test for multiple limit/group_policy qparams
-
https://review.openstack.org/#/c/576693/ Disable limits if force_hosts or force_nodes is set
-
https://review.openstack.org/#/c/576820/ Rename auth_uri to www_authenticate_uri
-
https://review.openstack.org/#/q/project:openstack/blazar+topic:bp/placement-api Blazar's work on using placement
End
You are the key to the coming revolution.