[openstack-dev] [nova] [placement] resource providers update 42
cdent+os at anticdent.org
Fri Nov 24 16:40:58 UTC 2017
This is update 42. Thanks to Eric for doing a few of these while I was
otherwise engaged. Thanks also for preserving the magical number 42.
It turns out the question for life, the universe and everything is the
rather mundane "what's up with placement?". Who knew?
I am not fully caught up on the state of things but will endeavor to
use my usual techniques to dig up pending changes relevant to
# Most Important
The three main themes (see below) remain the main focus. A fair few
bugs have been revealed during the creation the nested work and the
refactoring of the handling behind allocation candidates. Solutions
are in progress but there are likely others lurking so plenty of
review and experimentation is warranted.
# What's Changed
Not entirely sure. There's a lot of code to review but I'm not yet
aware of any fundamental changes of plan.
There's a topic of changes that are needed across the board to make
things proper and right that don't otherwise fit in a theme:
# Summit Actions
There was a placement update forum session, here is the etherpad:
One thing that surprised me from that session was that there was an
assumption that the idea of "consumer types" was well known. Maybe it
was but I didn't know it. The idea is that a set of allocations made
by one consumer could use a 'type' to indicate whether it is an
'instance' or 'volume' or 'migration'. The driving force is to be able
to distinguish between a 'migration' and 'instance' allocation when
in the middle of a migration. I thought we could do this a special
migration project or user id but apparently we want to be able to
account for the migration allocations when doing quota handling. It
seems a bit complicated but may be the right solution. One of the
todos from the etherpad is for the idea to get more socialization.
# Help Wanted
Another takeaway from summit is that we need, where possible,
benchmarking info from people who are making the transition from old
methods of scheduling to the newer allocation_candidate driven modes.
While detailed numbers will be most useful, even anecdotal summaries
of "woot it's way better" or "hmmm, no it seems worse" are useful.
There's an effort in progress to enhance the placement docs:
This is great to see. Docs needs continuous refactoring, they are
pretty much impossible to get perfect in one go.
# Main Themes
## Nested Providers
There's a lot of code on this topic
on both sides of the HTTP divide.
Related are granular resource requests, which allow, in part, traits on
specific nested providers (pairing a class with a trait, for example).
Some code for this is in place but the actual implementation is
Those two topics, plus
tie lots of things together.
## Alternate Hosts
Having the scheduler request and use alternate hosts is getting close:
## Migration allocations
Do allocation "doubling" using the migration uuid for the consumer for
one half. This is also very close:
The related work to allow changing multiple allocations in one POST
needs review. It is at the top of stack which clean up the allocations
skip authentication on root URI
(good to get this one in soon, is aligned with all the version
Build the placement osc plugin
These are fixes for the combination of resource providers being
wrong when shared providers are involved. These series may have been
superseded by the grand refactoring. If so it should be abandoned.
Re-use existing ComputeNode on ironic rebalance
Neutron's placement client
get_inventory for vmware driver
set accept to application/json if accept not set
cache-related headers for placement
request traits in nova
Extract instance allocation removal code
cover migration cases with functional tests
doc: note that custom resources are not fully supported
Only log not correcting allocation once per period
Remove the Pike migration code for flavor migration
Refactor placement version check
Add support for VGPU
Add 'CUSTOM_' prefix description in API ref
Put the json schema in their own directory
Add aggregate link note in API ref
Fix parameter order in placement API ref
Add 'Location' parameters in API ref
It's almost certain that I've missed a lot of things in making this
list. Please follow up with any additions you think are relevant and
that will get them on my radar for next time. There's a great deal to
review: we seem to keep coming up with worthwhile things to do.
Your prize for getting to the end is a post Thanksgiving meal nap, even
if you don't do Thanksgiving.
More information about the OpenStack-dev