Open Stack

On Thu, 2019-04-11 at 12:38 +0100, Chris Dent wrote:
> On Wed, 10 Apr 2019, Eric Fried wrote:
> 
> > I'll champion the one I described in the third comment at [4], where we
> > add a "mappings" dict next to "allocations". IMO, it's a tad cleaner
> > because it's per "allocations" rather than per "allocations.$rp". That
> > said, both of these options:
> >
> > - Provide the same information: which request groups got satisfied by
> > which providers [5].
> > - Violate the "black box" principle and require one side or the other to
> > work around it (either client removes or placement ignores the new key
> > on PUT /allocations). As I said further down in [4], I don't care about
> > that. (Ed?)
> > - Maintain the existing levels of hierarchy for the existing elements,
> > which Chris explained was important (see bottom five comments at [4]).
> 
> It's true that they do not change existing paths to existing data,
> but they do "invade" (as you say in your second point) existing data
> structures. The cleanest solution would probably be a new top-level
> key that provides the mapping information (line 426 on the spec),
> but as discussed there that ends up repeating too much information
> and needing ordering, because there's no independent identifier of a
> single allocation_request.
> 
> So yeah, one of those will do.
> 
> A moment to riff on one the points of having these conversations in
> the expanse of email:
> 
> To my internal unfettered brain the above sort-of-mess is yet more
> evidence that nested is a nightmare and gosh I wish we had never
> done: it, request groups, provider trees on the nova side, and pretty
> much all the stuff that's in progress related to enhanced platform
> awareness. It makes me squirm, see bad smells everywhere, and
> facepalm multiple times per day.
so just want to put this out there there is an alternitve  have placemetn be numa aware.

we can track all the resources in placement and we can pass allocation_candiates/provider_summaries
to the nova filters and we can have those filter eliminate invalid alloction_candiates based on numa
or any other chritia that placement does not understand.

we can do this today without modifying placements data structure although  we woudl still have to
create nested multiple resource provders per numa node but we dont need to have a nested treee.

this has a number of pros and cons.
the main cons being that nova need to contuie have non trivial filters and we will need to have
a limited abount of info in the resouce tracker(basically list of placemente RP uuids per numa node)
another con is that some of the allocation candiate returned will be invalid so it makes using limit
tricker but we can run out of allocation candiate already today because of filters so its not really any different.

on the pros side the placmenet team coudl focus on things it deem more important such as requirement from
projectes other then nova like shared storage. another pro of this would be we can still use placement for capsity and
traits and i also think its doable in train. the flat 2 level tree we create with vgpus or bandwith RPs can be used
for a lot of other usecases like jsut tracking sriov device, persitent memeory, cache basically any resouce that
you have multiple pools of on a comptue node can be tracked with just two levels. is we alway use group_policy=none
we can figutre out on the client side if the allcoation candiate meets our other constratis.

long term i think there is value in have richer query syntax in placement but if we need to pause
that to think about it some more, i think that is an ok viewpoint to express. i would personally prefer to
have a clean way to express requrement that is maintainable and does not tie our hands going forward.
again with that said if we decised not to use placment for numa in train i hope we can pusue using the
facilities that we already have to make some progress instead and not block those efforst on "we shoudl do this with
placemetn" if we have decided not to do them in placement in train. i know alot of nova folks
wont like that as it means we have to keep some of the complexity in nova but i would at least like to have
that conversation.

> I feel it is important that I get this off my chest and I encourage
> anyone else who has internal voices that don't feel enitirely
> appropriate go ahead and let them out as part of this pre-PTG email
> process. We are much more likely in the long term to be able to get
> things done in a useful fashion if we are able to honestly
> flush/vent such concerns in "public" and safely.
> 
> Because a lot of this stuff is the reality that we have and a
> situation that we need to solve. We can achieve the goals better by
> building up a shared language of what it is. That language includes
> the shit as well as the shine.
> 
> All that stuff above that I don't like at some gut level, I do like
> (or at least appreciate the value of) at a more practical level.
> 
> -- 
> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
> freenode: cdent                                         tw: @anticdent