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

Chris Dent cdent+os at anticdent.org
Fri Feb 2 12:33:24 UTC 2018


Here's resource provider and placement update 18-05. 18-04 was skipped
on account of illness.

# Most Important

Feature freeze has come and gone, RC1 is next week. This means that
finding bugs and, where relevant, reporting them with a tag of
'queens-rc-potential' is top priority.

The PTG is coming up at the end of this month. If you have topics for
discussion that are not already on the etherpad add them:

     https://etherpad.openstack.org/p/nova-ptg-rocky

I wrote a blog post to gather some thinking (and links) about
preparing to extract placement from nova (or at least ease the path
when it does eventually happen):

     https://anticdent.org/placement-extraction.html

It's probably time to start writing specs for some of the things we
know will be a big deal with placement in Rocky. Eric has started with
a spec that covers the ProviderTree work. Much of that work is already
done, but never had a spec in the first place:

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

I'm on the hook to create a spec for enabling generation handling when
associating aggregates. If there are others, getting them started
before the PTG can help to make the time at the PTG more effective.

# What's Changed

A limit is now passed to /allocation_candidates to ensure that we
don't cause out of memory errors in big empty clouds.

Traits expressed as 'required' in flavor extra specs are passed in
requests to placement and /allocation_candidates accepts the the
required parameter.

More, but not yet all, requests from nova to placement include the
global request id.

Some, but not all, of the ProviderTree functionality has merged.

The full stack of Alternate Hosts is now merged.

The ironic driver now manages traits.

At least some support for VGPU merged. Not clear what this means for
end users.

# Help Wanted

Testing, Testing, Testing.

There are a fair few unstarted bugs related to placement that could do
with some attention. Here's a handy URL: https://goo.gl/TgiPXb

# Main Themes

We've not yet identified the new themes, other than to know that
Nested remains a big deal.

## Nested Resource Providers

The work to get nested providers represented in the
/allocation_candidates did not complete before feature freeze. It
remains in progresss at

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

There's been a lot of discussion in IRC about the sometimes differing
goals on how people want NRP to work. One example is at:

     http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-29.log.html#t2018-01-29T15:01:24

There's an email thread related to that discussion:

     http://lists.openstack.org/pipermail/openstack-dev/2018-January/126651.html

I think we'll be doing ourselves a favor if we can work to satisfy concrete
use cases and then generalize from that.

The related provider tree work is now under its own topic:

     https://review.openstack.org/#/q/topic:bp/update-provider-tree

# Other

Plenty of these are bugs or fairly trivial and/or non-feature fixes.

* doc: mark the max microversions for queens
   https://review.openstack.org/#/c/539978/

* [Placement] Invalid query parameter could lead to HTTP 500
   https://review.openstack.org/#/c/539408/

* [placement] use simple FaultWrapper
   https://review.openstack.org/#/c/533752/

* Ensure resource classes correctly
   https://review.openstack.org/#/c/539738/

* Avoid inventory DELETE API (no conflict detection)
   https://review.openstack.org/#/c/539712/

* Do not normalize allocation ratios
   https://review.openstack.org/#/c/532924/

* Sending global request ids from nova to placement
     https://review.openstack.org/#/q/topic:bug/1734625

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

* Update resources once in update available resources
     https://review.openstack.org/#/c/520024/
     (This ought, when it works, to help address some performance
     concerns with nova making too many requests to placement)

* spec: treat devices as generic resources
     https://review.openstack.org/#/c/497978/
     This is a WIP and will need to move to Rocky

* Support aggregate affinity filters/weighers
     https://review.openstack.org/#/q/topic:bp/aggregate-affinity
     A rocky targeted improvement to affinity handling

* Move placement body samples in docs to own dir
     https://review.openstack.org/#/c/529998/

* Improved functional test coverage for placement
     https://review.openstack.org/#/q/topic:bp/placement-test-enhancement

* Functional tests for traits api
     https://review.openstack.org/#/c/524094/

* annotate loadapp() (for placement wsgi app) as public
     https://review.openstack.org/#/c/526691/

* Remove microversion fallback code from report client
     https://review.openstack.org/#/c/528794/

* WIP: SchedulerReportClient.set_aggregates_for_provider
     https://review.openstack.org/#/c/532995/
     This is likely for rocky as it depends on changing the api for
     aggregates handling on the placement side to accept and provide
     a generation

* Add functional test for two-cell scheduler behaviors
     https://review.openstack.org/#/c/452006/
     (This is old and maybe out of date, but something we might like to
     resurrect)

* Make API history doc consistent
     https://review.openstack.org/#/c/477478/

* WIP: General policy sample file for placement
     https://review.openstack.org/#/c/524425/

* Support relay RP for allocation candidates
    https://review.openstack.org/#/c/533437/
    Bug fix for sharing with multiple providers

* Convert driver supported capabilities to compute node provider
   traits
   https://review.openstack.org/#/c/538498/

# End

Usual caveats about missing things apply. One thing I'm curious to
know is: From an end user's perspective what does the queen's
placement work get ya?

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


More information about the OpenStack-dev mailing list