Open Stack

On Oct 31, 2014, at 9:27 PM, Robert Li (baoli) <baoli at cisco.com> wrote:

> 
> 
> On 10/28/14, 11:01 AM, "Daniel P. Berrange" <berrange at redhat.com> wrote:
> 
>> On Tue, Oct 28, 2014 at 10:18:37AM -0400, Jay Pipes wrote:
>>> On 10/28/2014 07:44 AM, Daniel P. Berrange wrote:
>>>> One option would be a more  CSV like syntax eg
>>>> 
>>>>   pci_passthrough_whitelist =
>>> address=*0a:00.*,physical_network=physnet1
>>>>   pci_passthrough_whitelist = vendor_id=1137,product_id=0071
>>>> 
>>>> But this gets confusing if we want to specifying multiple sets of data
>>>> so might need to use semi-colons as first separator, and comma for list
>>>> element separators
>>>> 
>>>>   pci_passthrough_whitelist = vendor_id=8085;product_id=4fc2,
>>> vendor_id=1137;product_id=0071
>>> 
>>> What about this instead (with each being a MultiStrOpt, but no comma or
>>> semicolon delimiters needed…)?

This is easy for a developer to access, but not easy for a deployer to make sure they have configured correctly because they have to keep up with the order of the options instead of making sure there is a new group header for each set of options.

>>> 
>>> [pci_passthrough_whitelist]
>>> # Any Intel PRO/1000 F Sever Adapter
>>> vendor_id=8086
>>> product_id=1001
>>> address=*
>>> physical_network=*
>>> # Cisco VIC SR-IOV VF only on specified address and physical network
>>> vendor_id=1137
>>> product_id=0071
>>> address=*:0a:00.*
>>> physical_network=physnet1
>> 
>> I think this is reasonable, though do we actually support setting
>> the same key twice ?

Yes, if it is registered in different groups.

>> 
>> As an alternative we could just append an index for each "element"
>> in the list, eg like this:
>> 
>> [pci_passthrough_whitelist]
>> rule_count=2
>> 
>> # Any Intel PRO/1000 F Sever Adapter
>> vendor_id.0=8086

Be careful about constructing the names. You can’t have “.” in them because then you can’t access them in python, for example: cfg.CONF.pci_passthrough_whitelist.vendor_id.0

>> product_id.0=1001
>> address.0=*
>> physical_network.0=*
>> 
>> # Cisco VIC SR-IOV VF only on specified address and physical network
>> vendor_id.1=1137
>> product_id.1=0071
>> address.1=*:0a:00.*
>> physical_network.1=physnet1
>> [pci_passthrough_whitelist]
>> rule_count=2
>> 
>> # Any Intel PRO/1000 F Sever Adapter
>> vendor_id.0=8086
>> product_id.0=1001
>> address.0=*
>> physical_network.0=*
>> 
>> # Cisco VIC SR-IOV VF only on specified address and physical network
>> vendor_id.1=1137
>> product_id.1=0071
>> address.1=*:0a:00.*
>> physical_network.1=physnet1
>> 
>> Or like this:
>> 
>> [pci_passthrough]
>> whitelist_count=2
>> 
>> [pci_passthrough_rule.0]
>> # Any Intel PRO/1000 F Sever Adapter
>> vendor_id=8086
>> product_id=1001
>> address=*
>> physical_network=*
>> 
>> [pci_passthrough_rule.1]
>> # Cisco VIC SR-IOV VF only on specified address and physical network
>> vendor_id=1137
>> product_id=0071
>> address=*:0a:00.*
>> physical_network=physnet1
> 
> Yeah, The last format (copied in below) is a good idea (without the
> section for the count) to handle list of dictionaries. I¹ve seen similar
> config examples in neutron code.
> [pci_passthrough_rule.0]
> # Any Intel PRO/1000 F Sever Adapter
> vendor_id=8086
> product_id=1001
> address=*
> physical_network=*
> 
> [pci_passthrough_rule.1]
> # Cisco VIC SR-IOV VF only on specified address and physical network
> vendor_id=1137
> product_id=0071
> address=*:0a:00.*
> physical_network=physnet1
> 
> Without direct oslo support, to implement it requires a small method that
> uses oslo cfg¹s MultiConfigParser().

I’m not sure what you mean needs new support? I think this would work, except for the “.” in the group name.

> 
> Now a few questions if we want to do it in Kilo:
>  ‹ Do we still need to be back-ward compatible in configuring the
> whitelist? If we do, then we still need to be able to handle the json
> docstring.

If there is code released using that format, you need to support it. You can define options as being deprecated so the new options replace the old but the old are available if found in the config file.

Doug

>  ‹ To support the new format in devstack, we can use meta-section in
> local.conf. how would we support the old format which is still json
> docstring?  Is something like this
> https://review.openstack.org/#/c/123599/ acceptable?
>  ‹ Do we allow old/new formats coexist in the config file? Probably not.
> 
> 
>> 
>>> Either that, or the YAML file that Sean suggested, would be my
>>> preference...
>> 
>> I think it is nice to have it all in the same file, not least because it
>> will be easier for people supporting openstack in the field. ie in bug
>> reports we cna just ask for nova.conf and know we'll have all the user
>> config we care about in that one place.
>> 
>> Regards,
>> Daniel
>> -- 
>> |: http://berrange.com      -o-
>> http://www.flickr.com/photos/dberrange/ :|
>> |: http://libvirt.org              -o-
>> http://virt-manager.org :|
>> |: http://autobuild.org       -o-
>> http://search.cpan.org/~danberr/ :|
>> |: http://entangle-photo.org       -o-
>> http://live.gnome.org/gtk-vnc :|
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev