[openstack-dev] [nova] placement/resource providers update 18

Chris Dent cdent+os at anticdent.org
Fri Apr 7 13:35:05 UTC 2017


There was a nova-specs sprint this week, so a lot of eyes were on
specs but there continues to be regular progress on resource
providers, the placement API and related work in the scheduler and
resource tracker. If you're doing work that I haven't noticed and
reported in here that you think should be, please follow up with
some links.

# What Matters Most

The addition of traits to the placement API is very close, one patch
remains. Linked below. That means that the top of the priority stack
is the spec for claims via the scheduler. Also linked below.

# What's Changed

There's a new spec for including user and project information in
allocations. This is a start towards allowing placement info to be
used for the counting required for quotas. There's a spec and a
followup review to fix some issues with it:

     http://specs.openstack.org/openstack/nova-specs/specs/pike/approved/placement-project-user.html
     https://review.openstack.org/#/c/454352/

# Help Wanted

Areas where volunteers are needed.

* General attention to bugs tagged placement:
     https://bugs.launchpad.net/nova/+bugs?field.tag=placement

* Helping to create api documentation for placement (see the Docs
     section below).

* Helping to create and evaluate functional tests of the resource
     tracker and the ways in which it and nova-scheduler use the
     reporting client. For some info see
     https://etherpad.openstack.org/p/nova-placement-functional
     and talk to edleafe.

* Performance testing. If you have access to some nodes, some basic
    benchmarking and profiling would be very useful. See the
    performance section below. Is there room on OSIC for this kind of
    thing?

# 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

There's one patch left to get the API in place and a patch for a new
command to sync the os-traits library into the database:

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

There is a stack of changes to the os-traits library to add more traits
and also automate creating symbols associated with the trait
strings:

     https://review.openstack.org/#/c/448282/4

## Ironic/Custom Resource Classes

There's a blueprint for "custom resource classes in flavors" that
describes the stuff that will actually make use of custom resource
classes:

     https://blueprints.launchpad.net/nova/+spec/custom-resource-classes-in-flavors

The spec has merged, but the implementation has not yet started.

Over in Ironic some functional and integration tests have started:

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

## Claims in the Scheduler

Progress has been made on the spec for claims in the scheduler:

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

Some differences of opinion on what's possible now and what the API
should expose have been resolved, but now we need to resolve some
questions on how (or even if) to most effectively deal with
reconciling allocations that used to happen in the resource tracker
and will now happen in the scheduler.

Eyes and brains required.

Thinking about this stuff has also revealed some places where it's
possible for allocations to become wrong or orphaned:

     https://bugs.launchpad.net/nova/+bug/1679750
     https://bugs.launchpad.net/nova/+bug/1661312

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

The spec for this has been updated with what was learned at the PTG
and moved to pike and merged:

     http://specs.openstack.org/openstack/nova-specs/specs/pike/approved/nested-resource-providers.html

## Docs

https://review.openstack.org/#/q/topic:cd/placement-api-ref

Several reviews are in progress for documenting the placement API.
This is likely going to take quite a few iterations as we work out
the patterns and tooling. But it's great to see the progress and
when looking at the draft rendered docs it makes placement feel like
a real thing™.

Find me (cdent) or Andrey (avolkov) if you want to help out or have
other questions.

## 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. Is this something where we could get time on the
OSIC hardware?

# Other Code/Specs

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

      This hasn't seen any attention since March 17, and as a result
      didn't get any attention during the spec sprint, so it might
      not make the freeze.

* https://review.openstack.org/#/c/448791/
     Idempotent PUT for resource classes. This is something that was
     discovered while evaluating some resource tracker code. Has a
     spec too:
     https://review.openstack.org/#/c/453732/

* 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

One of the best things about writing these things each week is I get
to see very clearly just how productive we're being in the realm of
placement. Thanks to everyone who is helping to make that possible.

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


More information about the OpenStack-dev mailing list