Open Stack

On 9 January 2014 20:19, Brian Schott <brian.schott at nimbisservices.com>wrote:

> Ian,
>
> The idea of pci flavors is a great and using vendor_id and product_id make
> sense, but I could see a case for adding the class name such as 'VGA
> compatible controller'. Otherwise, slightly different generations of
> hardware will mean custom whitelist setups on each compute node.
>

Personally, I think the important thing is to have a matching expression.
The more flexible the matching language, the better.

On the flip side, vendor_id and product_id might not be sufficient.
>  Suppose I have two identical NICs, one for nova internal use and the
> second for guest tenants?  So, bus numbering may be required.
>
> 01:00.0 VGA compatible controller: NVIDIA Corporation G71 [GeForce 7900
> GTX] (rev a1)
> 02:00.0 VGA compatible controller: NVIDIA Corporation G71 [GeForce 7900
> GTX] (rev a1)
>

I totally concur on this - with network devices in particular the PCI path
is important because you don't accidentally want to grab the Openstack
control network device ;)


> I know you guys are thinking of PCI devices, but any though of mapping to
> something like udev rather than pci?  Supporting udev rules might be easier
> and more robust rather than making something up.
>

Past experience has told me that udev rules are not actually terribly good,
which you soon discover when you have to write expressions like:

 SUBSYSTEM=="net", KERNELS=="0000:83:00.0", ACTION=="add", NAME="eth8"

which took me a long time to figure out and is self-documenting only in
that it has a recognisable PCI path in there, 'KERNELS' not being a
meaningful name to me.  And self-documenting is key to udev rules, because
there's not much information on the tag meanings otherwise.

I'm comfortable with having a match format that covers what we know and
copes with extension for when we find we're short a feature, and what we
have now is close to that.  Yes, it needs the class adding, we all agree,
and you should be able to match on PCI path, which you can't now, but it's
close.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140109/f93ccb49/attachment.html>