Open Stack

We had a brief conversation in the placement room yesterday
(Saturday May 5th) to confirm we were all on the same page with
regard to consumer types. These provide a way to say that a set of
allocations "is an instance" or "is a migration" and will help with
quota accounting.

We decided that since no one has stepped forward with a more
complicated scenario, at this time, we will go with the simplest
implementation, for now:

* add a consumer types table that has a key and string (length to be
   determined, values controlled by clients) that represents a "type".
   For example (1, 'instance')

* add a column on consumer table that takes one of those keys

* create a new row in the types table only when a new type is
   created, don't worry about expiring them

* provide an online migration to default existing consumers to
   'instance' and treat unset types as 'instance' [1]. This probably
   needs some confirmation from mel and others that it is suitable.
   If not, please provide an alternative suggestion.

* In a new microversion: allow queries to /usages to use a consumer
   type parameter to limit results to particular types and add
   'consumer_type' key will be added to the body of an 'allocations'
   in both PUT and POST.

* We did not discuss in the room, but the email thread [2] did: We
   may need to consider grouping /usages results by type but we could
   probably get by without changing that (and do multiple requests,
   sometimes).

Surya, thank her very much, has volunteered to work on this and has
started a spec at [3].

We have decided, again due to lack of expressed demand, to do any
work (at this time) related to resource provider partitioning [4].

There's a pretty good idea on how to do this, but enough other stuff
going on there's not time. Because we decided in that thread that
any one resource provider can only be in one partition, there is
also a very easy workaround: Run another placement server. It takes
only a few minutes to set one up [5]

This means that all of the client services of a single placement
service need to coordinate on what consumer types they are using.
(This was already true, but stated here for emphasis.)

[1] I'm tempted to test how long a million or so rows of consumers
would take to update. If it is short enough we may wish to break
with the nova tradition of not doing data migrations in schema
migrations (placement-manage db sync). But we didn't get a chance to
discuss that in the room.

[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/thread.html#4720

[3] https://review.opendev.org/#/c/654799/

[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004721.html

[5] https://docs.openstack.org/placement/latest/install/from-pypi.html

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