[openstack-dev] [placement][nova] Decision time on granular request groups for like resources

Chris Dent cdent+os at anticdent.org
Wed Apr 18 16:38:21 UTC 2018


On Wed, 18 Apr 2018, Jay Pipes wrote:

> Stackers,

Thanks for doing this. Seeing it gathered in one place like this in
neither IRC nor gerrit is way easier on my brain (for whatever
reason, don't know why).

> Eric Fried and I are currently at an impasse regarding a decision that will 
> have far-reaching (and end-user facing) impacts to the placement API and how 
> nova interacts with the placement service from the nova scheduler.

One thing that has felt like it is missing (at least not explicitly
present) in this discussion. We talk about this as if it will have
far reaching consequences, but it is not clear (to me at least) what
those consequences are, other than need to diddle yet more syntax
further down the line. Are there deeper consequences than that?

> In Viewpoint B, the proposal is to have a separate_providers=1,2 query 
> parameter that would indicate that the identified request groups should be 
> sourced from separate providers. Request groups that are not listed in the 
> separate_providers query parameter are not guaranteed to be sourced from 
> different providers.

Do I recall correctly that part of the motivation here (in viewpoint
B) is to be able to express: I'd like two disparate chunks of the same
class of inventory and while having them come from diffferent
providers it okay, it is also okay if they came from the same?

If that's correct, then that, to me, is fairly compelling if we are
thinking about placement over the long term outside the context of
solely satisfying nova workload placement.

> I'm, quite frankly, a bit on the fence about the whole thing and would just 
> like to have a clear path forward so that we can start landing the 12+ 
> patches that are queued up waiting for a decision on this.

yes

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


More information about the OpenStack-dev mailing list