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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
