Open Stack

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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>