Open Stack

On 7/7/2017 6:44 AM, Chris Dent wrote:
> 
> 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-allocation-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.
> 
> 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/placement-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.
> 
> 
> 
> __________________________________________________________________________
> 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
> 

Another thing to mention that wasn't in this list:

https://blueprints.launchpad.net/nova/+spec/custom-resource-classes-in-flavors

Ed got the part for the scheduler done, but there are two other changes 
needed for that blueprint. I also have a change up to amend the spec 
since it was missing some details:

https://review.openstack.org/#/c/481748/

-- 

Thanks,

Matt