[placement][nova][ptg] resource provider affinity
sbauza at redhat.com
Fri May 3 21:34:55 UTC 2019
On Fri, May 3, 2019 at 3:19 PM Chris Dent <cdent+os at anticdent.org> wrote:
> On Fri, 3 May 2019, Eric Fried wrote:
> >> Another alternative is having a "closure table" from where we can
> >> retrieve all the descendent rp ids of an rp without joining tables.
> >> but... online migration cost?
> > Can we consider these optimizations later, if the python-side solution
> > proves non-performant?
> My preference would be that we start with the simplest option (make
> multiple selects, merge them appropriately in Python) and, as Eric
> says, if that's not good enough, pursue the optimizations.
> In fact, I think we should likely pursue the optimizations  in
> any case, but they should come _after_ we have some measurements.
> Jay provided a proposed algorithm in .
That plan looks good to me, with the slight detail that I want to reinforce
the fact that python usage will have a cost anyway, which is to drift us
from the perfect world of having a distributed transactional model for
free. This is to say, we should refrain *at the maximum* any attempt to get
rid of SQL and use Python (or other tools) until we get a solid consensus
on those tools being as efficient and as accurately possible than the
We have a time slot tomorrow (Saturday May 3) at 13:30 to discuss
> some of the finer points of implementing nested magic .
I'll try to be present.
>  Making placement faster is constantly a goal, but it is a
> secondary goal.
> Chris Dent ٩◔̯◔۶ https://anticdent.org/
> freenode: cdent tw: @anticdent
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss