My proposals:
On 29 January 2014 16:43, Robert Li (baoli) <ba...@cisco.com> wrote:
> 1. pci-flavor-attrs is configured through configuration files and will be
> available on both the controller node and the compute nodes. Can the cloud
> admin decide to add a new attribute in a running cloud? If that's
> possible, how is that done?
>
When nova-compute starts up, it requests the VIF attributes that the
schedulers need. (You could have multiple schedulers; they could be in
disagreement; it picks the last answer.) It returns pci_stats by the
selected combination of VIF attributes.
When nova-scheduler starts up, it sends an unsolicited cast of the
attributes. nova-compute updates the attributes, clears its pci_stats and
recreates them.
If nova-scheduler receives pci_stats with incorrect attributes it discards
them.
(There is a row from nova-compute summarising devices for each unique
combination of vif_stats, including 'None' where no attribute is set.)
I'm assuming here that the pci_flavor_attrs are read on startup of
nova-scheduler and could be re-read and different when nova-scheduler is
reset. There's a relatively straightforward move from here to an API for
setting it if this turns out to be useful, but firstly I think it would be
an uncommon occurrence and secondly it's not something we should implement
now.
2. PCI flavor will be defined using the attributes in pci-flavor-attrs. A
> flavor is defined with a matching expression in the form of attr1 = val11
> [| val12 Š.], [attr2 = val21 [| val22 Š]], Š. And this expression is used
> to match one or more PCI stats groups until a free PCI device is located.
> In this case, both attr1 and attr2 can have multiple values, and both
> attributes need to be satisfied. Please confirm this understanding is
> correct
>
This looks right to me as we've discussed it, but I think we'll be wanting
something that allows a top level AND. In the above example, I can't say
an Intel NIC and a Mellanox NIC are equally OK, because I can't say (intel
+ product ID 1) AND (Mellanox + product ID 2). I'll leave Yunhong to
decice how the details should look, though.
3. I'd like to see an example that involves multiple attributes. let's say
> pci-flavor-attrs = {gpu, net-group, device_id, product_id}. I'd like to
> know how PCI stats groups are formed on compute nodes based on that, and
> how many of PCI stats groups are there? What's the reasonable guidelines
> in defining the PCI flavors.
>
I need to write up the document for this, and it's overdue. Leave it with
me.
--
Ian.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
