[openstack-dev] [nova] [placement] resource providers update 42

Chris Dent 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
placement.

# 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:

     https://review.openstack.org/#/q/topic:accumulated_nits

# Summit Actions

There was a placement update forum session, here is the etherpad:

     https://etherpad.openstack.org/p/SYD-forum-nova-placement-update

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.

# Docs

There's an effort in progress to enhance the placement docs:

     https://review.openstack.org/#/q/topic:bp/placement-doc-enhancement-queens

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

     https://review.openstack.org/#/q/topic:bp/nested-resource-providers

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
waiting:

     https://review.openstack.org/#/q/topic:bp/granular-resource-requests

Those two topics, plus

     https://review.openstack.org/#/q/topic:accumulated_nits

tie lots of things together.

## Alternate Hosts

Having the scheduler request and use alternate hosts is getting close:

     https://review.openstack.org/#/q/topic:bp/return-alternate-hosts

## Migration allocations

Do allocation "doubling" using the migration uuid for the consumer for
one half. This is also very close:

     https://review.openstack.org/#/c/507638/

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
representation:

    https://review.openstack.org/#/c/500073/

# Other

* https://review.openstack.org/#/c/522002/
   skip authentication on root URI
   (good to get this one in soon, is aligned with all the version
   discovery work)

* https://review.openstack.org/#/q/topic:bp/placement-osc-plugin
   Build the placement osc plugin

* https://review.openstack.org/#/q/topic:bug/1702420
   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.

* https://review.openstack.org/#/c/508555/
   Re-use existing ComputeNode on ironic rebalance

* https://review.openstack.org/#/c/511936/
   Neutron's placement client

* https://review.openstack.org/#/c/506175/
   get_inventory for vmware driver

* https://review.openstack.org/#/c/518223/
   set accept to application/json if accept not set

* https://review.openstack.org/#/c/521639/
   cache-related headers for placement

* https://review.openstack.org/#/q/topic:bp/request-traits-in-nova
   request traits in nova

* https://review.openstack.org/#/c/513041/
   Extract instance allocation removal code

* https://review.openstack.org/#/c/493865/
   cover migration cases with functional tests

* https://review.openstack.org/#/c/501252/
   doc: note that custom resources are not fully supported

* https://review.openstack.org/#/c/508262/
   Only log not correcting allocation once per period

* https://review.openstack.org/#/c/494206/
   Remove the Pike migration code for flavor migration

* https://review.openstack.org/#/c/512497/
   Refactor placement version check

* https://review.openstack.org/#/q/topic:bp/add-support-for-vgpu
   Add support for VGPU

* https://review.openstack.org/#/c/521495/
   Add 'CUSTOM_' prefix description in API ref

* https://review.openstack.org/#/q/topic:placement_schema_separation
   Put the json schema in their own directory

* https://review.openstack.org/#/c/521502/
   Add aggregate link note in API ref

* https://review.openstack.org/#/c/516233/
   Fix parameter order in placement API ref

* https://review.openstack.org/#/c/521541/
   Add 'Location' parameters in API ref

# End

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 mailing list