Placement Update 30
What Matters Most
Claims in the scheduler has merged, but first there was much gnashing
of teeth and pulling of hair at the many twisted webs we've weaved in
the scheduler and the resource tracker. While the base functionality
is now in master, it's not certain that it perfectly manages
allocations, especially in the case of move operations. Gibi has
started some tests to explore this. So far they are revealing more
So it would be fair to say that what matters most right now is
experimenting to see if the scheduler, resource tracker, and placement
service are doing the right things across a broad swathe of scenarios
and where possible writing functional tests that cover those
I thought there were going to be some changes to the resource tracker
made overnight, related to ensuring allocations on the source and
destination of a move are managed correctly, but I don't see them yet.
If they get pushed up today can someone followup here with links,
please? Or if it was decided that nothing was required can someone
Claims in the scheduler has merged:
The PlacementFixture now uses wsgi-intercept instead of spawning an
eventlet server. It's hoped this will help limit unpredictability in
Areas where volunteers are needed.
Claims in the Scheduler
Merged, and now being exposed to the hard cold light of reality.
Custom Resource Classes for Ironic
The spec is still pending, the work going ahead without it:
Updating flavors to include the resource class was merged, but then a
better place to do it was decided, that's here:
And a fix for a poorly behaving ironicclient:
(This section is unchanged since last time, as claims wins the
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
It's not yet clear if we'll want to support traits at both
/allocationcandidates and /resourceproviders. I think we should,
but the immediate need is on /allocation_candidates.
There's some proposed code to get /resource_providers started:
Shared Resource Providers
We decided that for the time being, /resourceproviders should not
return sharedproviders. A query against it is specifically about
providers that can satisfy the query in themselves.
Given that, there's nothing currently to do with this, other than the
general experimentation mentioned elsewhere. Notably, it's currently
unclear (in the sense that we don't have tests that prove it) whether
the resource tracker is wired up properly to not clobber allocations
the scheduler made which contain shared providers.
Nested Resource Providers
Work is paused on nested resource providers.
Lots of placement-related api docs have merged or are in progress:
Much of this is ready to go and just looking for a +W or a final +2
Setting up the official publishing job for the api ref is on hold
until the content has been migrated to the locations specified by the
docs migration that is currently in progress:
Some changes have been proposed to document the scheduler's
workflow, including visual aids, starting at:
Thanks for reading this far. I hope you reviewed some of the links
above. If not, please do. Otherwise no prize for you.
Chris Dent ┬──┬◡ﾉ(° -°ﾉ) https://anticdent.org/
freenode: cdent tw: @anticdent__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)