Here's update 33.
RC2 went to the presses. The result is that we've now got claims
happening earlier and using better information. This ought to mean
that there are fewer retries and failed builds. There's some
cruftiness in the code that manages allocations that will need to be
cleaned up, and bugs and buglets keep getting found in some edge cases
but overall much forward progress. Nice work everyone.
One alternate destinations is done, the next things coming up are
getting shared providers working on the nova side, incorporating
traits in resource requests, and, eventually, nested resource providers.
Presumably at the PTG we'll decide the if/when/how of extracting
placement to its own repo.
This week I've added a section that references bugs that have not yet
seen much action.
Besides reviewing all the stuff in this document, another important
thing to do is to make additions and edits on the PTG etherpad (see
The ongoing work with allocation related functional tests (many listed
below), and the getting alternate destinations working is also
There's a swathe of placement related stuff on the PTG planning
etherpad. Please add to that or make some adjustments if you think
something is missing or incomplete:
An important aspect of this is determining what kind of dependency
tree is involved with the work.
Also see this new next section.
Bugs needing attention
(Bugs which are not yet in progress or beyond.)
Old (need to be flushed or refreshed:?)
There's a stack that documents (with visual aids!) the flow of
scheduler and placement. It is pretty much ready:
There's a stack beginning at https://review.openstack.org/#/c/486215/
which proposes the bits necessary to return alternate destinations
besides the claimed destination. These will be used to do within-cell
(v2) retries in case a build can't be done on the claimed destiantion.
The spec revision for that work: https://review.openstack.org/#/c/471927/
Ed has some concerns about the complexity being created, so he wrote
up some issues at:
In his response to https://review.openstack.org/#/c/495854/3 Jay
suggests a named tuple:
I'm struck that instead of a two-tuple, both elements of the tuple
having lists of lists, would it not be clearer to have the return
value from select_destinations() instead be a single list of
namedtuple elements, where the namedtuple would have a
chosen_host, alternate_hosts, and allocation_requests attribute
Work continues apace on getting filtering by traits working:
This has some overlap with shared provider handling (below).
Shared Resource Providers
There's some support for shared resource providers on the placement
side of the scheduling equation, but the resource tracker is not yet
ready to support it. There is some work in progress, starting with
Nested Resource Providers
This will start back up after we clean off the windscreen. The stack
begins at https://review.openstack.org/#/c/470575/5
Chris Dent (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)