Open Stack

On Mon, May 6, 2019 at 1:54 AM, Chris Dent <cdent+os at 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.html#4720
> 
> [3] 
> https://protect2.fireeye.com/url?k=e2926c01-be19673d-e2922c9a-86ef624f95b6-55a34a8e4a7579ba&u=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://protect2.fireeye.com/url?k=b585a35f-e90ea863-b585e3c4-86ef624f95b6-8f691958e6e41ae2&u=https://anticdent.org/
> freenode: cdent                                         tw: @anticdent