This week in resource providers and placement we've been working to
merge some specs and verify in progress work.

# What Matters Most

As with last week, traits remain the top of the priority stack. The
spec for that merged this week so now the review focus changes to
the implementation. Links for that in the Themes section below.

# What's Changed

The ironic inventory handling work has led to a new get_inventory()
method in virt drivers:

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

The ironic implementation is the only one in progress thus far:

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

CORS support merged. If cors.allowed_origin is set in nova.conf it
is turned on for placement.

# Main Themes

## Traits

The work to normalize trait names (to be more like custom resource
classes) in the os-traits library has all merged, resulting in a new
release:

    https://pypi.python.org/pypi/os-traits

The work to implement the merged spec trait is ongoing at

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

There is a review to fix some typos in the spec:

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

## Shared Resource Providers

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

Progress on this will continue once traits 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.

## Claims in the Scheduler

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

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

As I say there, I think it is useful to discuss this stuff, but more
important to focus on getting what we already have working as that
will inform and change the future.

## 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://bugs.launchpad.net/nova/+bug/1635182
  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.

  Pushkar, you might want to make all of those have the same topic,
  or put them in a stack of related changes.

  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/status:open+topic:valid_inventories
  Fixes that ensure that we only accept valid inventories when setting
  them.

  Needs second +2.

* 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. The spec merged,
  this is the implementation. Open question on how to manage one
  of the utility functions therein.

* 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/382613/
   A little demo script for showing how a cronjob to update inventory
   on a shared resource provider might work. Last week I asked if
   this is still relevant and if not should I abandon it. I got no
   response, so it might be time to do so.

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

* https://review.openstack.org/#/c/429274/
   Clean up caches in the scheduler report client when a resource
   provider is deleted.

* https://review.openstack.org/#/c/442498/
   Gabbi test for invalid resource class name.

# End

Thanks for reading this far. Your reward is my sincere thanks and
credit in the beer bank.

--
Chris Dent                 ¯\_(ツ)_/¯           https://anticdent.org/
freenode: cdent                                         tw: @anticdent
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to