Open Stack

On Thu, 31 May 2018, Eric Fried wrote:

> But how would this be accomplished, in light of the current "separation
> of responsibilities" drawn at the virt driver interface, whereby the
> virt driver isn't supposed to talk to placement directly, or know
> anything about allocations?  Here's a first pass:

For sake of discussion, how much (if any) easier would it be if we
got rid of this restriction?

> the resource tracker that "inventory of resource class A on provider B
> have moved to provider C" for all applicable AxBxC.  E.g.

traits too?

> [ { 'from_resource_provider': <cn_rp_uuid>,
>    'moved_resources': [VGPU: 4],
>    'to_resource_provider': <gpu_rp1_uuid>
[snip]

> If we can do it this way, we don't need a migration tool.  In fact, we
> don't even need to restrict provider tree "reshaping" to release
> boundaries.  As long as the virt driver understands its own data model
> migrations and reports them properly via update_provider_tree, it can
> shuffle its tree around whenever it wants.

Assuming the restriction is kept, your model seems at least worth
exploring. The fact that we are using what amounts to a DSL to pass
some additional instruction back from the virt driver feels squiffy
for some reason (probably because I'm not wed to the restriction),
but it is well-contained.

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