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

Chris Dent cdent+os at anticdent.org
Fri Jan 6 13:19:18 UTC 2017


Welcome to the first placement/resource providers update for 2017.
There's a lot in progress, including plenty of work from new
contributors. Is great to see that.

# What Matters Most

The main priority remains the same: Getting the scheduler using a
filtered list of resource providers. That work is in progress near
here:

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

Falling out from that are a variety of bug fixes, and continued work
on aggregate handling and the resource tracker. There are links to
these things below.

# Stuff that's Different Now

Placement is running by default in devstack now, and thus running in
nova's gate as a matter of course. This unfortunately led to a brief
period where there was some collision with port handling with senlin,
but that was resolved.

The nova-status command now exists, and has support for indicating
whether the current deployment is ready to start using placement. That
was added (in part) by this:

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

# Stuff Needing a Plan

## Placement Client

We don't currently have an active plan for when we will implement a
placement client. Though we decided to not use a specific client in
the scheduler's report client (because simple requests+JSON works
just fine) we still have expectations that shared resource providers
will be managed via commands that can be run using the openstackclient.

Miguel Lavalle started work on a client
https://github.com/miguellavalle/python-placementclient/tree/adding-grp-support

## Placement Docs

The initial work for having placement-api-ref documentation has
started at

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

but sdague has appropriately pointed out that we're going to need gate
automation to draft and publish the results. Having two api-refs in
one repo complicates this a bit.

## can_host, aggregates in filtering

There's still some confusion (from at least me) on whether the
can_host field is relevant when making queries to filter resource
providers. Similarly, when requesting resource providers to satisfy a
set of resources, we don't (unless I've completely missed it) return
resource providers (as compute nodes) that are associated with other
resource providers (by aggregate) that can satisfy a resource
requirement. Feels like we need to work backwards from a test or use
case and see what's missing.

# Pending Planned Work

## Dev Documentation

Work has started on documentation for developers of the placement API.
The first part of that work is published at

     http://docs.openstack.org/developer/nova/placement_dev.html

The rest of it is under review starting at

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

(I'm listing this near the top because the information there is coming
into the world later than it should have, and is proving useful for
people with questions on how to make changes.)

## Resource Tracker Cleanup and Use of Resource Classes For Ironic

The cleanup to the resource tracker so that it can be more effective
and efficient and work correctly with Ironic continues in the
custom-resource-classes topic:

     https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/custom-resource-classes

## Handling Aggregates in Placement Server and Clients

There are a few bits of work in place to make sure aggregates can be
used in the placement service. This is important because it's the way
that resource A (a compute node) can use resource B (some shared disk)
but resource C (a compute node in a different rack) cannot.

This means that the client side needs to know which aggregates a
resource provider is associated with:

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

And the server side needs to be able to report those resource
providers which are members of any of a list of aggregates:

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

What we haven't got yet is paying attention to aggregates when
filtering available resource providers by resources. From last week:

     As this work emerges, we'll need to make sure that both the client
     and server sides are aware of aggregate associations as "the
     resource providers that the placement service returns will either
     have the resources requested or will be associated with aggregates
     that have providers that match the requested resources."

Miguel's neutron work (below) found a missing feature in existing
aggregate handling: We need to know uuids!

     https://bugs.launchpad.net/nova/+bug/1652642

Jay started a fix:

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

but it needs a spec:

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

# Stuff Happening Outside of Nova

* Puppet and TripleO doing Placement
   https://review.openstack.org/#/q/topic:placement+status:open+owner:%22Emilien+Macchi+%253Cemilien%2540redhat.com%253E%22

* Neutron IPV4 Inventory
   https://review.openstack.org/#/c/358658/

# Bugs, Pick up Work, and Miscellaneous

* Allocation bad input handling and dead code fixing
   https://review.openstack.org/#/c/416751/

   While fixing sending allocations with a value of 0 blowing up the
   universe some code that was not particularly robust was discovered
   and while poking at that we all realized "aw hell, some of this code
   is dead, let's remove it". The stack above fixes both of those
   things.

* Small improvements to placement.rst
   https://review.openstack.org/#/c/403811/

* Update the generic resource pools spec to reflect reality
   https://review.openstack.org/#/c/407562/

* [WIP] Placement api: Add json_error_formatter to defaults
   https://review.openstack.org/#/c/395194/

   This is an effort to avoid boilerplate, but no good solution has
   been determined yet. Reviewers can help us figure a good way to
   handle things.

* Demo inventory update script:
   https://review.openstack.org/#/c/382613/

   This one might be considered a WIP because how it chooses to do
   things (rather simply and dumbly) may not be in line with expecations.

* CORS support in placement API:
   https://review.openstack.org/#/c/392891/

* Fix typo in config of auth middleware
   https://review.openstack.org/#/c/417178/

   The typo was identified back in November, but because the bug never
   got tagged 'placement' it got lost in the fray. The typo currently
   doesn't cause broken behaviour but would if we ever changed how
   placement is deployed.

* Better debug logging on inventory update failures
   https://review.openstack.org/#/c/414230/

   The request-id wasn't being recorded, which makes it difficult to
   associate client side logs with server side logs.

* Capacity exceeded logging is in the wrong place
   https://review.openstack.org/#/c/410128/

# Post Ocata

I think the following tracks of work are for after Ocata. Please
correct me if I'm wrong.

## Resource Provider Traits

Proof of concept work on resource provider traits is seeing plenty of
activity lately. This is the functionality that will allow people to
express requirements and preferences about qualitative aspects of
resources.

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

Spec:

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

## Nested Resource Providers

This is moving along at:

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

An issue was identified with how some PCI devices are identified in a
non-globally unique fashion, requiring adding a uuid field to the
pci_device object and model:

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

(uuid's everywhere please!)

## Delete all Inventory

Working with the placement API from the resource tracker identified an
inefficient with the API: it's hard to delete all of one resource
provider's inventory in one request if it has more than one class of
resource. Work is planned to fix it:

     spec: https://review.openstack.org/#/c/415885/
     imp:  https://review.openstack.org/416669

# End

As we approach feature freeze it is inevitable we will find bugs,
missing logs, and misunderstandings, just like we did at the end of
the last cycle. It's the nature of these things. Thanks to everyone
who helped out and persevered last cycle we got some good stuff out
the door. Thanks to those people and anyone else who helps out this
time, we'll do it again.

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


More information about the OpenStack-dev mailing list