This week's resource providers/placement update operates only
slightly as a summary of placement-related activity at least week's
PTG. We had a big etherpad of topics
https://etherpad.openstack.org/p/nova-ptg-pike-placement
and an entire afternoon (plus some extra time elsewhen) to cover
them, but really only addressed three of them (shared resource
handling, custom resource classes, traits) in any significant
fashion, touching on nested-resource providers a bit in the room and
claims in the placement service on the etherpad. Some summation of
that below.
# What Matters Most
A major outcome from the discussion was that the can_host/shared
concept will not be used for dealing with shared resources (such as
shared disk). Instead a resource provider that is a compute node
will be identified by the fact that it has a trait (the actual value
to be determined). When the compute node creates or updates its own
resource provider it will add that trait. When the nova-scheduler
asks for resources to filter it will include that trait.
This means that the traits spec (and its POC) is now priority one in
the placement universe:
https://review.openstack.org/#/c/345138/
# What's Changed
## Ironic Inventory
There was some debate about where in the layering of code within
nova-compute that the creation of custom resource classes should be
handled. Having these is necessary for the effective management of
ironic nodes. The discussion resulted in this new version of ironic
inventory handling:
https://review.openstack.org/#/c/437602/
## Nested Resource Providers
There was some discussion at a flipboard about the concept of
resource providers with multiple parents. We eventually decided
"let's not do that". There was also some vague discussion about
whether it was possible to express a hardware configuration that is
currently planned to be expressed as nested resource providers as
instead a custom resource class, along the lines of how bare metal
configurations are described. This was left unresolved, in part
because presumably hardware configuration is dynamic in some or
many cases.
# Main Themes
## Traits
There's been a decision to normalize trait names so they look a bit
more like custom resource classes. That work is at
https://review.openstack.org/#/q/status:open+project:openstack/os-traits+branch:master+topic:normalize
This is being done concurrently with the spec and code for traits
within placement/nova:
https://review.openstack.org/#/q/status:open+topic:bp/resource-provider-traits
https://review.openstack.org/#/q/status:open+topic:bp/resource-provider-tags
(That topic mismatch needs to be fixed.)
## Shared Resource Providers
As mentioned above, the plan on this work has changed, thus there is
currently no code in flight for it, but there is a blueprint:
https://blueprints.launchpad.net/nova/+spec/shared-resources-pike
## Nested Resource Providers
https://review.openstack.org/#/q/status:open+topic:bp/nested-resource-providers
## Docs
https://review.openstack.org/#/q/topic:cd/placement-api-ref
The start of creating an API ref for the placement API. Not a lot
there yet as I haven't had much of an opportunity to move it along.
There is, however, enough there for additional content to be
started, if people have the opportunity to do so. Check with me to
divvy up the work if you'd like to contribute.
## Claims in the Scheduler
We intended to talk about this at the PTG but we didn't get to it.
There was some discussion on the etherpad (linked above) but the
consensus was that planning for how to do this while the service
was a) still evolving, b) only just starting to do filtering was
premature: Anything we try to plan now will likely be wrong or at
least not aligned with eventual discoveries. We decided, instead,
that the right thing to do was to make what we've got immediately
planned work correctly and to get some real return on the promise of
the placement API (which in the immediate sense means getting shared
disk managed effectively).
## Performance
Another topic we didn't get to. We're aware that there are some
redundancies in the resource tracker that we'd like to clean up
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110953.html
but it's also the case that we've done no performance testing on the
placement service itself. For example, consider the case where a
CERN-sized cloud is turned on (at Ocata) for the first time. Once
all the nodes have registered themselves as resource providers the
first request for some candidate destinations in the filter
scheduler will get back all those resource providers. That's
probably a waste on several dimensions and will get a bit loady.
We ought to model both these exterme cases and the common cases to
make sure there aren't unexpected performance drains.
## Microversion Handling on the Nova side
Matt identified that we'll need to be more conscious of micoversions
in nova-status, the
