Le 09/12/2016 15:50, Chris Dent a écrit : > > 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/ >
Given that now we have an agreement, I'll provide the scheduler client change by the next week. -Sylvain > ## 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. > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
