Open Stack

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?

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