Open Stack

December? Wherever does the time go? This is resource providers and
placement update 43. The first one of these was more than a year ago

     http://lists.openstack.org/pipermail/openstack-dev/2016-November/107171.html

I like to think they've been pretty useful. I know they've helped me
keep track of stuff, and have a bit of focus. I'll carry on doing them
but I'm starting to worry that they are getting too big, both to read
and to create, and that this means something, not sure what, for the
volume of work we're trying to accomplish. There's so much work going
on all the time related to placement, writing it down in one place is
rather challenging, so surely creating and reviewing it all is also
challenging? And that's not taking into consideration the vast volume
of all the other stuff within the nova umbrella. Not sure what to do
about it, but something to start thinking about.

# Most Important

The vast and intertwingled mass which is nested resource providers, a
variety of database cleanups, traits handling, assorted bugfixes and
test additions is probably the best place to focus some attention.
Many things hinge on that work. One entry point is the topic for the
n-r-p blueprint:

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

# What's Changed

Microversions 1.12 and 13 of the placement API have merged. These add
a new dict-like representation for PUTting
/allocations/{consumer_uuid} (for sake of symmetry with GET) and allow
POSTting multiple allocations (including clearing them) to
/allocations.

https://docs.openstack.org/nova/latest/user/placement.html#put-dict-format-to-allocations-consumer-uuid

The backend for nested resource providers is in place, but the HTTP
API for that has not yet been exposed (it's very close). This, along
with others changes, has meant some changes to all the database
handling, so there's some potential for bugs to be exposed, be on the
lookout.

Matt learned that when some people are migrating to newer versions of
Nova that require placement, their internal policy handling is not
aligning with the very simple (intentionally so) way that placement
handles policy. If people don't have an 'admin' role, placement won't
go and patches like this are required:

     https://gist.github.com/mgagne/b43c1e085c1f1d50bebc054a7d387688

To start thinking about dealing with this Matt's posted a
policy-in-code that generates a sample policy:

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

One of the goals of placement has been to minimize config files and
configurability, but apparently this is something that is going to
need some degree of flexibility.

# Help Wanted

A 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. Additional
docs-related chanages:

* https://review.openstack.org/#/c/512215/
   Add create inventories doc for placement

* https://review.openstack.org/#/c/523007/
   Add x-openstack-request-id in API ref

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

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

* https://review.openstack.org/#/c/511342/
   add API reference for create inventory

## Nested Providers

As mentioned above 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.

## 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 concept of migration allocations is what drove the work to enable
the POST /allocations handling now at microversion 1.13, so we have
the option to start using that power. Dan helpfully left comments in
the code to indicate where it could be done.

## Misc Traits, Shared, Etc Cleanups

There's a stack of code that's not attached to a blueprint, starting
at

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

that fixes up a lot of things related to traits, sharing providers,
test additions and fixes to those tests. At the moment they are a bug
topic:

     https://review.openstack.org/#/q/topic:bug/1702420

But that is not the only bug they are addressing. Some of the above
probably appear in the list below too.

# Other

This list starts with in progress bug fixes that I can find. After
that it is uncategorized other stuff. Note that a lot of the
uncategorized stuff is good changes that will improve things but
don't seem to see a lot of review because they are not in the main
themes. If we have time, we may as well get them in too, as we'll only
have to deal with them later if not.

* https://review.openstack.org/#/c/524088/
   Fix an error message in API validation (for traits)

* https://review.openstack.org/#/c/523403/
   re-use existing conf with auth token middleware

* https://review.openstack.org/#/c/522002/
   skip authentication on root URI

* https://review.openstack.org/#/c/522407/
   Add aggregates check in allocation canditates

* https://review.openstack.org/#/c/519462/
   Log options at debug when starting API services under wsgi
   (Make any sense to split this into placement and nova versions? One
   seems easier than the other)

* https://review.openstack.org/#/c/523192/
   Use oslo_db Session in resource_provider.py

* https://review.openstack.org/#/c/516880/
   Fix foreign key constraint error (unable to delete resource provider
   if it has traits)

* https://review.openstack.org/#/c/518223/
   set accept to application/json if accept not set
   (and thus get structured error responses)

* https://review.openstack.org/#/c/506175/
   VMware: implement get_inventory() driver method

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

* https://review.openstack.org/#/c/524263/
   Proper error handling by _ensure_resource_provider
   (This is already approved for master, but there are backports.)

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

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

* 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/#/q/topic:placement_schema_separation
    Put the json schema in their own directory

# End

There's way more than enough here but I'm sure I've missed some
things. Feel followup with corrections.

Your prize for reading this far is that you'll get another one next
week.

-- 
Chris Dent                      (⊙＿⊙')         https://anticdent.org/
freenode: cdent                                         tw: @anticdent