Open Stack

On Thu, 11 Apr 2019, Sean Mooney wrote:
> 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 think the pros you present (and other have presented) are (and
have been) strong enough that doing NUMA via nested-in-placement is
the right way to go. The gist of my prior rant is not so much that I
don't like nested but that I don't like the reasons for its
existence (NUMA and other hardware awarenesses) and the costs from
those reasons. The resolve is: I have to get past that; it's what
we've got. Since that's what we've got may as well be placement that
makes it cleaner. It's good for that sort of thing.

But it also means that I will sometimes be compelled to defend the
simpler way, as at the "horrible idea" in my comment at
https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/2005385-allocation-candidates-subtree-affinity.rst@182

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent