[placement][nova][ptg] Summary: Consumer Types
balazs.gibizer at ericsson.com
Mon May 6 09:33:36 UTC 2019
On Mon, May 6, 2019 at 1:54 AM, Chris Dent <cdent+os at anticdent.org>
> 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' . 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.
> * 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  did: We
> may need to consider grouping /usages results by type but we could
> probably get by without changing that (and do multiple requests,
> Surya, thank her very much, has volunteered to work on this and has
> started a spec at .
> We have decided, again due to lack of expressed demand, to do any
> work (at this time) related to resource provider partitioning .
> 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 
> 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.)
>  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.
>  https://docs.openstack.org/placement/latest/install/from-pypi.html
> Chris Dent ٩◔̯◔۶
> freenode: cdent tw: @anticdent
More information about the openstack-discuss