Comment 20 for bug 1778591

@cdent: A consumer is the abstract thing that has one or more resources allocated to it. While currently only representing a Nova instance, a consumer may in the future represent a Nova instance, a (detached) Cinder volume, a (detached) Neutron port or any other thing that can have allocations associated with it.

We could probably make the same argument that you are making about the concept of a resource provider... "it's just a UUID that has inventory (and traits) associated with it." Why do we need to have a GET /resource_providers endpoint at all? Why not just use GET /inventories/{uuid} where {uuid} is just the "external identifier" for the thing that has inventory of resources?

And my answer to that is because conceptually it makes sense to name the thing that has some other relation associated with it. That's the basis of entity-relationship modeling that I'm familiar with, at least :)

From a less-abstract-less-Jay's-personal-need-for-congruence perspective, I've been thinking about this issue with regards to how we tackle the pile of technical debt that is called "instance groups" in Nova. In order to solve various affinity and anti-affinity problems -- which are inherently a placement/scheduling domain -- the relationship between two consumers needs to be modeled.

We currently model this in Nova-land with the instance_groups and instance_group_member (sic) and instance_group_policy (sic) tables that live in the nova_api database [1].

I personally believe it would be easier to solve distance and affinity constraints in the placement service if the placement service were the thing to understand the relationship between different consumers (i.e. the groups the consumers belong to). The reason I believe this is that placement is really the only service (other than Keystone) that has a truly global view [2]. If we keep the table that stores instance group membership in Nova, then we limit the ability of Nova to group instances across multiple Nova deployments (this is going to be critical for edge deployments, BTW).

Similarly, if we keep the instance group membership in Nova, we have no ability to group dissimilar types of consumers together (e.g. group a Nova instance, a (detached) Neutron network and a (detached) Cinder volume together...)

In order to have instance^Wconsumer group information in placement, we'll need some way of associating a consumer with another consumer. We could do that explicitly with some sort of "consumer group" concept. Or we could do it implicitly using a generic "tags" concept (which was my original idea for implementing instance groups in Nova after I saw the proposed implementation). Regardless of whether we went with an explicit groups or implicit tags model, we would still want *some* entity other than "an external identifier for a set of allocations" to be available in our API for associating one consumer to another :)

We would most naturally do that using something like:

 PUT /consumer_groups/group1
 {
   "members": [
      "consumer1",
      "consumer2",
      ...
   ]
 }

or:

 PUT /consumers/consumer1/tags
 {
   "tags": [
     "group1"
   ]
 }
 PUT /consumers/consumer2/tags
 {
   "tags": [
     "group1"
   ]
 }

Either way, though, requires^Wencourages that the concept of a "consumer" be more solid -- and represented via the API -- than the ghostly apparition of a consumer concept we currently have today. Would you agree with this statement?

Anyway, these are just brain farts at the moment. Curious what you, Eric and Ed think of the above stream of thought...

Best,
-jay

[1] https://github.com/openstack/nova/blob/5d748001c2ffb1197ff991ca69a95865087f1010/nova/db/sqlalchemy/api_models.py#L402-L461

[2] Well, not *truly* global until we add support for a partition/source/shard concept/field that will be able to differentiate between multiple Nova deployments :)