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@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-p... -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent