Open Stack

2017-07-07 19:44 GMT+08:00 Chris Dent <cdent+os at anticdent.org>:

>
> After 40 days in the desert I've returned with placement update 27.
>
> Unfortunately, as far as I can tell, no one did any updates while I
> was gone so I don't have anything to crib from to have the full
> story on what's going on. I suspect I will miss some relevant
> reviews when making this list. If I have, please let me know.
> Otherwise, let's begin:
>
> # What Matters Most
>
> Claims in the scheduler remains the key feature we'd like to get in
> before feature freeze. After some hiccups on how to do it, making
> requests of the new /allocation_candidates (of which more, below) is
> the way to go. Changes for that are starting at
>
>     https://review.openstack.org/#/c/476631/
>
> # What's Changed
>
> As mentioned, there's now a new URL in the placement API:
> GET /allocation_candidates. It has a similar interface to GET
> /resource_providers (in that you can filter the results by the kind
> of resources required) but the information is formatted as a
> two-tuple of lists of allocation requests and a dictionary of
> resource provider information. The latter will provide the initial
> list of available resource providers and augment the process of
> filtering and weighing those providers. The former provides a
> collection of correctly formed JSON bodies that can be sent in a PUT
> to /allocations/{consumer_uuid} when making a claim.
>
> I'm still a bit confused about where the concept of "alternatives"
> that are going to be passed to the cell conductors fits into this,
> but I guess that will become more clear soon.
>
> It also seems like this model creates a pretty strong conceptual
> coupling between a thing which behaves like a nova-scheduler
> (request, process, then claim resources). As placement becomes
> useful to other services it will be important to revisit some of
> these decisions and make sure the HTTP API is not imposing too many
> behaviuor requirements on the client side (otherwise why bother
> having an HTTP API?). But that's for later. Right now we're on a
> tight schedule trying to make sure that claims get in in Ocata.
>
> Because there's a bit of a dependency hierarchy with the various
> threads of work going on in placement, the work on claims may punt
> traits and/or nested resource providers further down the timeline.
> Work continues on all three concurrently.
>
> Another change is that allocations now include project id and user
> id information and usages by those id can be retrieved.
>
> # Help Wanted
>
> Areas where volunteers are needed.
>
> * General attention to bugs tagged placement:
>              https://bugs.launchpad.net/nova/+bugs?field.tag=placement
>
> # Main Themes
>
> ## Claims in the Scheduler
>
> As described above there's been a change in direction. That probably
> means some or all of the code now at
>
>     https://review.openstack.org/#/q/status:open+topic:bp/placement-claims
>
> can be abandoned in favor of the work at
>
>     https://review.openstack.org/#/q/topic:bp/placement-allocati
> on-requests+status:open
>
> The main starting point for that is
>
>     https://review.openstack.org/#/c/476631/
>
> ## Traits
>
> The concept of traits now exists in the placement service, but
> filtering resource providers on traits is in flux. With the advent
> of /allocation_candidates as the primary scheduling interface, that
> needs to support traits. Work for that is in a stack starting at
>
>     https://review.openstack.org/#/c/478464/
>
> It's not yet clear if we'll want to support traits at both
> /allocation_candidates and /resource_providers. I think we should,
> but the immediate need is on /allocation_candidates.
>

For traits support in /allocation_candidates, I started some patches:
https://review.openstack.org/478464
https://review.openstack.org/479766
https://review.openstack.org/479776


>
> There's some proposed code to get the latter started:
>
>     https://review.openstack.org/#/c/474602/


>
> ## Shared Resource Providers
>
> Support for shared resource providers is "built in" to the
> /allocation_candidates concept and one of the drivers for having it.
>
> ## Nested Resource Providers
>
> Work continues on nested resource providers.
>
>       https://review.openstack.org/#/q/status:open+topic:bp/nested
> -resource-providers
>
> The need with these is simply more review, but they are behind
> claims in priority.
>
> ## Docs
>
> Lots of placement-related api docs have merged or are in progress:
>
>     https://review.openstack.org/#/q/status:open+topic:cd/placem
> ent-api-ref
>
> Shortly there will be a real publishing job:
>
>     https://review.openstack.org/#/c/480991/
>
> and the tooling which tests that new handlers are documented
> will be turned on:
>
>     https://review.openstack.org/#/c/480924/
>
> Some changes have been proposed to document the scheduler's
> workflow, including visual aids, starting at:
>
>     https://review.openstack.org/#/c/475810/
>
> # Other Code/Specs
>
> * https://review.openstack.org/#/c/472378/
>    A proposed fix to using multiple config locations with the
>    placement wsgi app. There's some active discussion on whether the
>    solution in mind is the right solution, or even whether the bug is
>    a bug (it is!).
>
> * https://review.openstack.org/#/c/470578/
>    Add functional test for local delete allocations
>
> * https://review.openstack.org/#/c/427200/
>       Add a status check for legacy filters in nova-status.
>
> * https://review.openstack.org/#/c/469048/
>     Provide more information about installing placement
>
> * https://review.openstack.org/#/c/468928/
>     Disambiguate resource provider conflict message
>
> * https://review.openstack.org/#/c/468797/
>     Spec for requesting traits in flavors
>
> * https://review.openstack.org/#/c/480379/
>   ensure shared RP maps with correct root RP
>   (Some discussion on this one what the goal is and whether the
>   approach is the right one.)
>
> # End
>
> That's all I've got this week, next week I should be a bit more
> caught up and aware of any bits I've missed. No prize this week, but
> maybe next week.
>
> --
> Chris Dent                  ┬──┬◡ﾉ(° -°ﾉ)       https://anticdent.org/
> freenode: cdent                                         tw: @anticdent
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170708/0853142a/attachment.html>