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__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
