Open Stack

On Tue, 16 Apr 2019, Jay Pipes wrote:
> On 04/16/2019 01:38 PM, melanie witt wrote:
>> On Tue, 16 Apr 2019 10:33:45 -0700, Dan Smith <dms at danplanet.com> wrote:
>>> I guess it seems more like it needs to be (loosely) an enum within a
>>> given shard. Like "I'm nova, my shard is $UUID and within that shard, my
>>> consumer types are instance, migration, etc". Might also be "I'm ironic,
>>> my shard is $UUID and within that shard, my consumer types are
>>> nova-instance, standalone-use, etc".
>>> 
>>> I don't really want to codify the enum in placement, as I think it's
>>> just a key that the consuming service uses to correlate the "reason" for
>>> each allocation. Some (like nova) could be a static small enum, but for
>>> others it could need to be dynamic and scale per tenant or something
>>> like that.

[snip]

>> +1 to all of this.

> Yeah, +1 from me as well. Great point about the migrations being separate 
> consumer type than instance.

For reference, there's also some discussion in IRC [1] with me, Dan,
Jay.

The summary, if I'm understanding correctly, is something like this:

The thing we want is a "consumer type", it is used to distinguish
one type of a consumer (and thus group of allocations representing a
"workload") from another. For example "these allocations are for an
instance", "these are for a migration".

Different services will need to be in charge of the distinctions
they want to make. We can't predict all those services and distinctions,
therefore placement should not be authoritative on types, each
service is.

In any given deployment, collaborating services (like nova, neutron,
ironic, cinder) would need to agree on how they are not overlapping.
That's out of scope for the placement side of things, but not
irrelevant generally.

>From an implementation standpoint, if/when we do this that makes
consumer type a string associated with a consumer. To get overly
detailed for this level of discussion: Since there will be a lot of
duplication we should probably normalize it out to its own table.

When a /usages query is made, the consumer type could be optionally
expressed, limiting results. Are multiple types something that needs
to be expressed in one query? Not yet discussed.

There's been no discussion yet about how the consumer type would be
expressed when an allocation is written. Nor whether it will be
required and what happens with existing consumers that don't have
it.

And most importantly, no volunteers for the work. Interested?

Ideally, if we want to do this in Train, we'd have someone owning this
before the PTG.

Thanks.

[1] http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-04-16.log.html#t2019-04-16T17:58:38k

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