Sorry, addressing gaffe, bringing this back on-list... On 04/18/2018 04:36 PM, Ed Leafe wrote: > On Apr 18, 2018, at 4:11 PM, Eric Fried <openst...@fried.cc> wrote: >>> That makes a lot of sense. Since we are already suffixing the query param >>> “resources” to indicate granular, why not add a clarifying term to that >>> suffix? E.g., “resources1=“ -> “resources1d” (for ‘different’). The exact >>> string we use can be bike shedded, but requiring it be specified sounds >>> pretty sane to me. >> I'm not understanding what you mean here. The issue at hand is how >> numbered groups interact with *each other*. If I said >> resources1s=...&resources2d=..., what am I saying about whether the >> resources in group 1 can or can't land in the same RP as those of group 2? > OK, sorry. What I meant by the ‘d’ was that that group’s resources must be > from a different provider than any other group’s resources (anti-affinity). > So in your example, you don’t care if group1 is from the same provider, but > you do with group2, so that’s kind of a contradictory set-up (unless you had > other groups). > > Instead, if the example were changed to > resources1s=...&resources2d=..&resources3s=…, then groups 1 and 3 could be > allocated from the same provider. > > -- Ed Leafe
This is a cool idea. It doesn't allow the same level of granularity as being able to list explicit group numbers to be [anti-]affinitized with specific other groups - but I'm not sure we need that. I would have to think through the use cases with this in mind. -efried __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
