Open Stack

Gary
         Firstly, thanks for your review very much.
         The pci_stats is calculated in the resource tracker in the compute node and is also saved in compute_node, I think currently the scheduler depends on the information provided by the compute_node table so this method should fit into current framework.
         Please notice that the scheduler only decide the host that can meet the requirement, and it's the resource tracker in compute node that will do the real device allocation. So if scheduler does not get the latest information, it may either can't find the host, or, it finds a host with wrong information and the re-try mechanism should work. Anyway, this is same to other compute nodes information like free_ram or free_vcpus, right?

         But you does remind me one thing, that if a hot plug happens , after the resource tracker select the device and before the instance is really created. Possibly the virt driver need check the requirement before create the domain. But this race condition chain will not end. After all, there are window between the virt driver check and the instance creation, and no idea how can we guarantee this.

Thanks
--jyh

From: Gary Kotton [mailto:gkotton at vmware.com]
Sent: Wednesday, August 28, 2013 2:19 AM
To: OpenStack Development Mailing List (openstack-dev at lists.openstack.org)
Subject: [openstack-dev] [Nova] Scheduler support for PCI passthrough

Hi,
Whilst reviewing the code I think that I have stumbled on an issue (I hope that I am mistaken). The change set (https://review.openstack.org/#/c/35749/) expects pci stats to be returned from the host. There are a number of issues here that I have concern with an would like to know what the process is for addressing the fact that the compute node may not provide these statistics, for example, this could be due to the fact that the driver has not been updated to return the pci stats or this could be if the scheduler has been upgraded prior to the compute node (what is the process for the upgrade).
Thanks
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130828/01e096d0/attachment.html>