Open Stack

On Nov 4, 2014, at 2:07 PM, Robert Li (baoli) <baoli at cisco.com> wrote:

> 
> 
> On 11/3/14, 6:32 PM, "Doug Hellmann" <doug at doughellmann.com> wrote:
> 
>> 
>> 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.
> 
> The group header is not fixed in this case. Let’s replace “.” with “:”,
> then the user may have configured multiple groups such as
> [pci_passthrough_rule:x]. With oslo, how would you register the group and
> the options under it and access them as a list of dictionaries?

First, you MUST pick a separator character that results in the group name being a valid python variable name. So, instead of “:” use “_”. That gives you “pci_passthrough_rule_x”. Then you just pass that name when you register the list of options. See the second example under http://docs.openstack.org/developer/oslo.config/cfg.html#option-groups

Knowing which groups must exist is a separate problem, and solving that depends on the application. A common solution is to have a single option win a well-known group with a list of the names. For example, “pci_passthrough_rules = x, y, z” can be converted into the longer group names to register the option groups and then access their values.

> 
>> 
>>> 
>>> 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
>> 
>> 
>> _______________________________________________
>> 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