Open Stack

This week in resource providers and placement the main news is we've
made a change in priorities, see "What's Changed" below. If this
update seems more terse or more riddled with errors than usual, I
blame the great scheduler in the sky placing a virus upon me that is
messing with my savoir faire.

# What Matters Most

Traits remain the top of the priority stack. Links below in themes.

# What's Changed

A fair bit.

Currently the CachingScheduler does not make use of the placement
API, only the FilterScheduler does. Thus from the standpoint of a
CachingScheduler-using deployment the placement API isn't providing
much in the way of visible value yet. It was assumed that not many
people are using the CachingScheduler but apparently this is not the
case. We would like to get rid of the CachingScheduler for the sake
of both cellsv2 and placement, but we cannot do this until we get
claims in the scheduler (and against the placement api).

Therefore the priorities are being adjusted so that claims are above
shared resoures and nested resource providers, but below traits and
ironic inventory. See this message and the surrounding thread for
more details:

     http://lists.openstack.org/pipermail/openstack-dev/2017-March/113839.html

In that same thread we also decided that we will continue to forego
creating a full-blown python-placementclient and instead will make
an openstackclient plugin for CLI operations against the placement
API:

     http://lists.openstack.org/pipermail/openstack-dev/2017-March/113932.html

And again, in the same thread, we declared that we should begin the
work to extract placement to its own repo shortly after claims in
the scheduler has stabilized (the hoped for target is early Queens).
This provides a good platform on which to manage backports in case
we break stuff.

There are two new utility methods which make some placement
framework things a bit simpler:

* https://review.openstack.org/#/c/444497/
   Adds a `raise_http_status_code_if_not_version` method which is
   handy when adding functionality in a new microversion.

* webob.dec.wsgify replaced by wsgi_wrapper.PlacementWsgify
   Done in https://review.openstack.org/#/c/395194/ a while back but
   perhaps not socialized enough. This makes it so the
   json_error_formatter keyword doesn't need to be used everywhere a
   webob.exc is raised.

# Main Themes

## Traits

The work to implement the traits API in placement is happening at

     https://review.openstack.org/#/q/status:open+topic:bp/resource-provider-traits

## Ironic/Custom Resource Classes

The work to support custom resource classes provided by the Ironic
virt driver has merged

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

There are test improvements on the same BP

     https://review.openstack.org/#/q/status:open+topic:bp/custom-resource-classes-pike

They are part of a drive to improve the functional testing of the
compute side of the interactions with the placement API to make sure
we fully understand and have test coverage for the flow of events.

jroll has started a spec for "custom resource classes in flavors"
that describes the stuff that will actually make use of this
functionality:

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

Over in ironic some functional and integration tests have started:

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

## Claims in the Scheduler

A "Super WIP" spec for claims in the scheduler was started at

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

Since we've bumped this up the priority chain we will need to give
these concepts some real attention. The WIP spec has a lot of how
and not enough what or why.

## Shared Resource Providers

https://blueprints.launchpad.net/nova/+spec/shared-resources-pike

Progress on this will continue once traits and claims have moved forward.

## Nested Resource Providers

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

According to mriedem, the nested-resource provider spec
<https://review.openstack.org/#/c/386710/> should be updated to
reflect the flipboard discussion from the PTG (reported in this
space last week) about multi-parent providers and how they aren't
going to happen. Previous email:

      http://lists.openstack.org/pipermail/openstack-dev/2017-March/113332.html

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

## Performance

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.

We ought to do some testing to make sure there aren't unexpected
performance drains.

# Other Code/Specs

* https://review.openstack.org/#/c/441881/
    Checking for placement microversion 1.4 in nova-status.

* https://review.openstack.org/#/q/topic:bug/1635182+status:open
    Fixing it so we don't have to add json_error_formatter everywhere.
    There's a collection of related fixes attached to that bug report.

    These are basically ready and besides cleaning up some boilerplate
    in the code, help make sure that error output is consistent.

* https://review.openstack.org/#/q/topic:bug/1673227
   More robust jsonschema for inventory and allocation
   representations.

* https://review.openstack.org/#/c/416751/
    Removing the Allocation.create() method which was only ever used in
    tests and not in the actual, uh, creation of allocations.

* https://review.openstack.org/#/c/416669/
    DELETE all inventories on one resource provider. Needs one more
    +2.

* https://review.openstack.org/#/c/418393/
   A spec for improving the level of detail and structure in placement
   error responses so that it is easier to distinguish between
   different types of, for example, 409 responses.

* https://review.openstack.org/#/c/423872/
     Spec for versioned-object based notification of events in the
     placement API. We had some discussion in the weekly subteam
     meeting about what the use cases are for this, starting

     http://eavesdrop.openstack.org/meetings/nova_scheduler/2017/nova_scheduler.2017-03-06-14.00.log.html#l-120

     The gist is: "we should do this when we can articulate the
     problem the notifications will solve". Comment on the review if
     you have some opinions on that.

* https://review.openstack.org/#/c/436773/
     Removing SQL from exception messages.

* https://bugs.launchpad.net/nova/+bug/1661312
     Race condition for allocations during evacuation. Known bug, not
     sure of solution.

* https://bugs.launchpad.net/nova/+bug/1632852
     Cache headers not produced by placement API. This was assigned to
     several different people over time, but I'm not sure if there is
     any active code.

* https://etherpad.openstack.org/p/placement-newton-leftovers
     There's still some lingering stuff on here, some of which is
     mentioned elsewhere in this message, but not all.

# End

Thanks (again?) for reading this far.

-- 
Chris Dent                 ¯\_(ツ)_/¯           https://anticdent.org/
freenode: cdent                                         tw: @anticdent