[openstack-dev] [nova] [placement] placement update 18-31

Chris Dent cdent+os at anticdent.org
Fri Aug 3 13:45:13 UTC 2018

HTML: https://anticdent.org/placement-update-18-31.html

This is placement update 18-31, a weekly update of ongoing development 
related to the [OpenStack](https://www.openstack.org/) [placement 

# Most Important

We are a week past feature freeze for the Rocky cycle, so finding
and fixing bugs through testing and watching launchpad remains the
big deal. Progress is also being made on making sure the Reshaper
stack (see below) and using consumer generations in the report
client are ready as soon as Stein opens.

# What's Changed

A fair few bug fixes and refactorings have merged in the past week,
thanks to everyone chipping in. The functional differences you might
see include:

* Writing allocations is retried server side up to ten times.
* Placement functional tests are using some of their own fixtures
   for output, log, and warning capture. This may lead to different
   output when tests fail. We should fix issues as they come up.
* Stats handling in the resource tracker is now per-node, meaning it
   is both more correct and more efficient.
* Resource provider generation conflict handling in the report
   client is much improved.
* When using force_hosts or force_nodes, limit is not used when
   doing GET /allocation_candidates.
* You can no longer use unexpected fields when writing allocations.
* The install guide has been updated to include instructions about
   the placement database.

# Bugs

* Placement related [bugs not yet in progress](https://goo.gl/TgiPXb):
    16, +2 from last week.
* [In progress placement bugs](https://goo.gl/vzGGDQ) 12, -1 on last

# Main Themes

## Documentation

Now that we are feature frozen we better document all the stuff. And
more than likely we'll find some bugs while doing that documenting.

Matt pointed out in response to last week's pupdate that the two
bullets that had been listed here are no longer valid because we
punted on most of the functionality (fully working shared and nested
providers) that needed the docs.

However, that doesn't mean we're in the clear. A good review of
existing docs is warranted.

## Consumer Generations

These are in place on the placement side. There's pending work on
the client side, and a semantic fix on the server side, but neither
are going to merge this cycle.

* <https://review.openstack.org/#/c/579163/>
    return 404 when no consumer found in allocs

* <https://review.openstack.org/#/c/583667/>
    Use placement 1.28 in scheduler report client
    (1.28 is consumer gens, which we hope to have ready for immediate
    Stein merge)

## Reshape Provider Trees

Work has restarted on framing in the use of the reshaper from the
compute manage. It won't merge for Rocky but we want it ready as
soon as Stein opens.

It's all at: <https://review.openstack.org/#/q/topic:bp/reshape-provider-tree>

## Extraction

A lot of test changes were made to prepare for the extraction of
placement. Most of the remaining "uses of nova" in placement are
things that will need to wait to post-extraction, but it is useful
and informative to look at imports as there are some thing

On the [PTG etherpad](https://etherpad.openstack.org/p/nova-ptg-stein)
I've proposed that we consider stopping forward feature progress on
Placement in Stein so that:

* We can given nova some time to catch up and find bugs in existing
   placement features.
* We can do the extraction and large backlog of refactoring work
   that we'd like to do.

That is at a list item of 'What does it take to declare placement

# Other

Going to start this list with the 5 that remains from the 11 (nice
work!) that were listed last week. After that will be anything else
I can find.

* <https://review.openstack.org/#/c/537614/>
     Add unit test for non-placement resize

* <https://review.openstack.org/#/c/568639/>
     Use placement.inventory.inuse in report client

* <https://review.openstack.org/#/c/582899/>
    Delete allocations when it is re-allocated
    (This is addressing a TODO in the report client)

* <https://review.openstack.org/#/c/583489/>
    Remove Ocata comments which expires now

* <https://review.openstack.org/#/c/523006/>
    Ignore some updates from virt driver

* <https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placement-api>
   Neutron work related to minimum bandwidth handling with placement

* <https://review.openstack.org/#/c/553461/>
   Resource provider examples (in osc-placement)

* <https://review.openstack.org/#/c/527791/>
   Get resource provider by uuid or name (in osc-placement)

* <https://review.openstack.org/#/c/586056/>
   Provide a useful message in the case of 500-error (in

* <https://review.openstack.org/#/c/586839/>
   Add image link in README.rst (in osc-placement)

* <https://review.openstack.org/#/c/542745/>
   Random names for [osc-placement] functional tests

* <https://review.openstack.org/#/c/588470/>
   Fix nits in resource_provider.py

* <https://review.openstack.org/#/c/588350/>
   [placement] Debug log per granular request group

* <https://review.openstack.org/#/c/584218/>
   Consider forbidden traits in early exit of _get_by_one_request

* <https://review.openstack.org/#/c/585672/>
   Enable nested allocation candidates in scheduler

* <https://review.openstack.org/#/q/topic:refactor-fixture>
   Placement fixture refactorings and cleanups

* <https://review.openstack.org/#/c/561770/>
   PCPU: Define numa dedicated CPU resource class

* <https://review.openstack.org/#/c/567191/>
   Imposing restrictions on resource providers create uuid

# End

This is the last one of these I'm going to do for a while. It's less
useful at the end and beginning of the cycle when there are often
plenty of other resources shaping our attention. Also, I pretty
badly need a break and an opportunity to more narrowly focus on
fewer things for a while (you can translate that as "get things done
rather than tracking things"). Unless someone else would like to
pick up the mantle, I expect to pick it back up sometime in
September. Ideally someone else would do it. It's been a very
useful tool for me, and I hope for others, so it's not my wish that
it go away.

Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent

More information about the OpenStack-dev mailing list