Open Stack

A shorter resource provider placement update this week. In part this
is because some of the things to think about from last week[0] got
resolved. What's below is essentially a collection of pending work
related to resource providers and the placement API that needs review
and/or discussion.

[0] http://lists.openstack.org/pipermail/openstack-dev/2016-December/108395.html

# Pending Planned Work

## Update Client Side to Consider Aggregates

After having this in the things to think about section last week,
Jay's posted the start of the resource tracker work[1] which attends
to aggregates. Above that are some placement API changes for getting a
list of resource providers that are members of any of the provided
aggregates.

[1] https://review.openstack.org/#/c/407309/

## Update Scheduler to Request Limited Resource Providers

The debate on GET v POST and which URL to use for filtering resource
providers resolved and the implementation looks good[2]. Once that's
in we can start work on adjust the scheduler, keeping in mind what I
quoted from Jay last week:

        we will only return resource providers to the scheduler that
        are compute nodes in Ocata. 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.

[2] https://review.openstack.org/#/c/392569/

## Docs

I've started a placement_dev.rst[3] (miles to go yet) and will start
on the api-ref soon after that. placement_dev (and its cousin
placement.rst) need some input on what people would like to see in
those files.

[3] https://review.openstack.org/#/c/408313/

## Custom Resource Classes

This is moving along with some of the stack of code[4] having merged.
There was some discussion in IRC worth mentioning:

* There's still an unresolved question on how we are going to express
   certain custom resource class scenarios in build requests,
   especially from the ironic standpoint. The consensus at this point
   is: a) probably something extra_spec-like for now b) it will be
   better when we're expressing requirements and preferences more
   explicitly (eschewing flavors).

* There's some concern from some that we should be focussing on the
   resource tracker doing allocations of the standard compute node
   resources and the scheduler using the limited list of resource
   providers, only, and not yet worrying about additional features like
   custom resource classes. The counter to those concerns is that
   perhaps we can and should do both?

[4] https://review.openstack.org/#/c/398469/

## Nested Resource Providers

Percolating and moving forward.[5]

[5] https://review.openstack.org/#/c/377138/

## Make Resource Providers not Remotable

(This is part of long term work to ensure that the placement service
is easy to extract.)

The code[6] is in progress, but there are some questions on how best
to test or enforce the plan. I've left some clarifying questions that
I hope Sylvain or someone else can clear up so I can get this
finished.

[6] https://review.openstack.org/#/c/404279/

# Pending Pickup Work

(Bugs[7], stuff from the leftovers etherpad[8], other random bits of
improvement.)

[7] https://bugs.launchpad.net/nova/+bugs?field.tag=placement
[8] https://etherpad.openstack.org/p/placement-newton-leftovers

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

* Handling limits in schema better
    https://review.openstack.org/#/c/399002/ (needs review)

* [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
    hande 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/

* Do not post allocations that are zero
   https://review.openstack.org/#/c/407180/

* Cascade delete of RP aggregate associations
   https://review.openstack.org/#/c/407707/

* Improve the error message for failed RC deletion
   https://review.openstack.org/#/c/406149/

* Add a retry loop to ResourceClass creation
   https://review.openstack.org/#/c/399170/

   There is a race condition in the creation of custom resource clases.

# End

Thanks for reading. Please post questions if you have them.

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