On Wed, 18 Apr 2018, Eric Fried wrote:
I have a feeling we're just going to go back and forth on this, as we
have for weeks now, and not reach any conclusion that is satisfactory to
everyone. And we'll delay, yet again, getting functionality into this
release that serves 90% of use cases because we are obsessing over the
0.01% of use cases that may pop up later.
So I vote that, for the Rocky iteration of the granular spec, we add a
single `proximity={isolate|any}` qparam, required when any numbered
request groups are specified. I believe this allows us to satisfy the
two NUMA use cases we care most about: "forced sharding" and "any fit".
And as you demonstrated, it leaves the way open for finer-grained and
more powerful semantics to be added in the future.
The three most important priorities for me (highest last) are:
* being able to move forward quickly so we can learn from our
mistakes sooner than later and not cause backlogs in our progress
* the common behavior should require the least syntax. Since (I
hope) the common behavior has nothing to do with nested, and the
syntax under discussion only comes into play on granular requests,
it's not really germane here. But it bears repeating that we are
outside the domain of useful stuff for most cloudy people, here.
* the API needs to have an easy mental process for translating from
human utterances to a set of query parameters and vice versa. This
is why I tend to prefer a single query parameter (like either of
the two original proposals in this thread, or 'proximity) to
encoded parameters (like 'resources1{s,d}') or taking the leap
into a complex JSON query structure in a POST.
One of the advantages of microversions is that we can easily change
it later if we want. It can mean that the underlying data query code
may need to branch more, but that's the breaks, and isn't really
that big of a deal if we're maintaining our tests well.
It is more than likely that we will eventually have to move to POST
at some point (and at that point it wouldn't be completely wrong to
investigate graphql). But we should put that off and let ourselves
progress there in a stepwise fashion.
Let's take one or two use cases, solve for them in what we hope is a
flexible fashion, and move on. If we get it wrong we can fix it. And
it'll be okay. Let's not maintain this painful illusion that we're
writing stone tablets.
--
Chris Dent ٩◔̯◔۶ https://anticdent.org/
freenode: cdent tw: @anticdent__________________________________________________________________________
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
