Open Stack

>
> OK - so if this is good then I think the question is how we could change
the 'pci_whitelist' parameter we have - which, as you say, should either
*only* do whitelisting or be renamed - to allow us to add information.
 Yongli has something along those lines but it's not flexible and it
distinguishes poorly between which bits are extra information and which
bits are matching expressions (and it's still called pci_whitelist) - but
even with those criticisms it's very close to what we're talking about.
 When we have that I think a lot of the rest of the arguments should simply
resolve themselves.
>
>
>
> [yjiang5_1] The reason that not easy to find a flexible/distinguishable
change to pci_whitelist is because it combined two things. So a
stupid/naive solution in my head is, change it to VERY generic name,
‘pci_devices_information’,
>
> and change schema as an array of {‘devices_property’=regex exp,
‘group_name’ = ‘g1’} dictionary, and the device_property expression can be
‘address ==xxx, vendor_id == xxx’ (i.e. similar with current white list),
 and we can squeeze more into the “pci_devices_information” in future, like
‘network_information’ = xxx or “Neutron specific information” you required
in previous mail.


We're getting to the stage that an expression parser would be useful,
annoyingly, but if we are going to try and squeeze it into JSON can I
suggest:

{ match = { class = "Acme inc. discombobulator" }, info = { group = "we
like teh groups", volume = "11" } }

>
> All keys other than ‘device_property’ becomes extra information, i.e.
software defined property. These extra information will be carried with the
PCI devices,. Some implementation details, A)we can limit the acceptable
keys, like we only support ‘group_name’, ‘network_id’, or we can accept any
keys other than reserved (vendor_id, device_id etc) one.


Not sure we have a good list of reserved keys at the moment, and with two
dicts it isn't really necessary, I guess.  I would say that we have one
match parser which looks something like this:

# does this PCI device match the expression given?
def match(expression, pci_details, extra_specs):
   for (k, v) in expression:
        if k.starts_with('e.'):
           mv = extra_specs.get(k[2:])
        else:
           mv = pci_details.get(k[2:])
        if not match(m, mv):
            return False
    return True

Usable in this matching (where 'e.' just won't work) and also for flavor
assignment (where e. will indeed match the extra values).

> B) if a device match ‘device_property’ in several entries, raise
exception, or use the first one.

Use the first one, I think.  It's easier, and potentially more useful.

> [yjiang5_1] Another thing need discussed is, as you pointed out, “we
would need to add a config param on the control host to decide which flags
to group on when doing the stats”.  I agree with the design, but some
details need decided.

This is a patch that can come at any point after we do the above stuff
(which we need for Neutron), clearly.

> Where should it defined. If we a) define it in both control node and
compute node, then it should be static defined (just change pool_keys in
"/opt/stack/nova/nova/pci/pci_stats.py" to a configuration parameter) . Or
b) define only in control node, then I assume the control node should be
the scheduler node, and the scheduler manager need save such information,
present a API to fetch such information and the compute node need fetch it
on every update_available_resource() periodic task. I’d prefer to take a)
option in first step. Your idea?

I think it has to be (a), which is a shame.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140111/7f17bb11/attachment.html>