This is update 38. It is confused because last week's update said in
the subject that is was 36 but in the body that it was 37. It was 37.
Most important is simply making progress on the stuff that's
outstanding. There's enough in progress, with its related
dependencies, we pretty much just need to keep pushing things forward.
During the scheduler team meeting it was decied that the root provider
should be represented when showing a nested resource provider resource.
Previously it was just going to be the parent (which could be used to
traverse to the root)
There are still a few specs pending that are interdependent with the
main themes so would be good to get reviewed:
Nested Resource Providers
While working on nested resource providers it became clear there was
a lot of mixed up cruft in the resource provider objects, so before
the nested work there is now
which is a stack of cleanups to how the SQL is managed in there. The
nested resource providers work is at:
This spec is important for making effective use of nested providers:
And the work to make traits work is relevant here, because with traits
nested aren't near as useful:
The migration allocations work is happening at:
Management of those allocations currently involves some raciness,
birthing the idea to allow POST /allocations, some of the
code for that is in progress at
There are two outstanding bits of spec required for that:
We want to be able to do retries within cells, so we need some
alternate hosts when returning a destination that are structured
nicely for RPC:
Matt has recently pointed out that this stuff may cause some hiccups
with the CachingScheduler that we'll need to resolve in some fashion,
either by making it work, documentating that it doesn't work, or...?
There's almost certainly more. Please add to the list if I've left off
Your prize this week is a personal invitation to the TC elections.
Chris Dent (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)