Open Stack

On Mon, 8 Apr 2019, Chris Dent wrote:

> * would make things like "resource provider affinity" above easier.
>  much easier. and let us express granular-ness less awkwardly, and
>  let us add new and richer group_policy concepts (which is
>  basically the affinity thing).
>
>    * Brought up briefly in the above spec at
>      https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/2005385-allocation-candidates-subtree-affinity.rst@184
>
> As clients making GET /allocation_candidates queries desire to
> express more and more complexity [2], query parameters start to feel
> cumbersome. At various times people have suggest that a JSON body
> might be easier to manage. The first time was during the discussion
> that resulted in the creation of the allocation_candidates resource.

In one of the other threads yesterday, Eric and I were batting about
terms like "unified solution" and "unified theory" [1]. I was trying to
suggest that if we could come up with a grand unified theory of
nested resource providers that would make it easier for us to come
up with a solution to the various nested goals that are on the go
right now. One that feels consistent and sensible.

I think there's still room for discussion on that tack, on that thread,
despite it seeming a bit stalled out, but wanted to also try a different
approach over here, to see if it might be productive:

Suppose we did have an in-body JSON syntax to make topologically complex
queries for allocation candidates. Would it be able to provide both
a unified solution and a unified theory of nested operation? If so,
that (especially the latter) would be a pretty compelling reason to
have it, despite my other reservations.

Ideas?

A naive model would be to represent a graph of resource requirements
in JSON and then search for branches of trees which are coincident
with that graph. In its most naive form this would not easily
represent requirements where arbitrarily large gaps, either
parent or sibling-oriented in the graph, may acceptably satisfy a
query. That is, there are intervening structural providers that
"don't matter" to the requester.

The problem expressed there is a derivation of some of the problems
we've been expressing elsewhere (things like the need to use
references to other resource group identifiers in the values of
query parameters). Presumably the solution is similar in either
context.

Pushing out a bit, if we went for a syntax like GraphQL, the same
problem will be present there, but I would expect recursive or
gapped queries to be a thing that community has addressed. Does
anyone know?

To add a little more clarity on the concept of "unified theory of
operation", if we had one it would be the case that when anyone
introduced a new idea we could see how it felt with regard to the
theory and say, quickly/intuitively, "yeah that fits" or "no that
doesn't fit". That we have the following:

* some people who think that a theory exists, but it is a different
   theory from some other people who also think that a theory exists

* some people who are involved regularly who don't think a theory
   exists

suggests that things could be better and despite how annoying
talking it out might seem, it's useful.

The theory doesn't have to mean that everything is explained and
decided. Nor does it mean that things cannot change. It's simply a
set of contextual constraints, which if present would probably help
us move things long more quickly than we have a history of doing.

It also doesn't mean we can't do things piecemeal. We must be able
to do piecemeal and be able to change things later. The theory helps
provide some boundaries or encapsulation.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005201.html

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