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-requ...@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

__________________________________________________________________________
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

Reply via email to