On Tue, May 29, 2018 at 9:38 AM, Sylvain Bauza <sba...@redhat.com>
wrote:
On Tue, May 29, 2018 at 3:08 AM, TETSURO NAKAMURA
<nakamura.tets...@lab.ntt.co.jp> wrote
> In that situation, say for example with VGPU inventories, that
would mean
> that the compute node would stop reporting inventories for its
root RP, but
> would rather report inventories for at least one single child RP.
> In that model, do we reconcile the allocations that were already
made
> against the "root RP" inventory ?
It would be nice to see Eric and Jay comment on this,
but if I'm not mistaken, when the virt driver stops reporting
inventories for its root RP, placement would try to delete that
inventory inside and raise InventoryInUse exception if any
allocations still exist on that resource.
```
update_from_provider_tree() (nova/compute/resource_tracker.py)
+ _set_inventory_for_provider() (nova/scheduler/client/report.py)
+ put() - PUT /resource_providers/<rp_uuid>/inventories with
new inventories (scheduler/client/report.py)
+ set_inventories() (placement/handler/inventory.py)
+ _set_inventory()
(placement/objects/resource_proveider.py)
+ _delete_inventory_from_provider()
(placement/objects/resource_proveider.py)
-> raise exception.InventoryInUse
```
So we need some trick something like deleting VGPU allocations
before upgrading and set the allocation again for the created new
child after upgrading?
I wonder if we should keep the existing inventory in the root RP, and
somehow just reserve the left resources (so Placement wouldn't pass
that root RP for queries, but would still have allocations). But
then, where and how to do this ? By the resource tracker ?
AFAIK it is the virt driver that decides to model the VGU resource at a
different place in the RP tree so I think it is the responsibility of
the same virt driver to move any existing allocation from the old place
to the new place during this change.
Cheers,
gibi
-Sylvain
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev