2017-07-07 19:44 GMT+08:00 Chris Dent <cdent...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
