On Mon, May 6, 2019 at 1:54 AM, Chris Dent <cdent+os@anticdent.org> wrote:
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.
If there are ongoing migration then defaulting the consumer type to instance might be incorrect. However nova already has a mechanism to distingush between migration and instance consumer so nova won't break by this. Still nova might want to fix this placement data inconsistency. I guess the new placement microversion will allow to update the consumer type of an allocation. Cheers, gibi
* 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.htm...
[4] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004721.htm...
[5] https://docs.openstack.org/placement/latest/install/from-pypi.html
-- Chris Dent ٩◔̯◔۶ https://protect2.fireeye.com/url?k=b585a35f-e90ea863-b585e3c4-86ef624f95b6-8f691958e6e41ae2&u=https://anticdent.org/ freenode: cdent tw: @anticdent