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/20...
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.htm... -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent