[placement][ptg] Allocation Partitioning

melanie witt melwittt at gmail.com
Tue Apr 16 21:22:37 UTC 2019

On Tue, 16 Apr 2019 20:12:36 +0100 (BST), Chris Dent 
<cdent+os at anticdent.org> wrote:
> 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.

I must admit that this last paragraph makes the idea of codifying the 
consumer types in placement more appealing. Guess it's a trade-off on 
where the effort goes. Projects collaborating to avoid overlap vs a 
heavier process and implementation for placement to provide the consumer 


More information about the openstack-discuss mailing list