On Nov 4, 2014, at 2:07 PM, Robert Li (baoli) <ba...@cisco.com> wrote:
> > > On 11/3/14, 6:32 PM, "Doug Hellmann" <d...@doughellmann.com> wrote: > >> >> On Oct 31, 2014, at 9:27 PM, Robert Li (baoli) <ba...@cisco.com> wrote: >> >>> >>> >>> On 10/28/14, 11:01 AM, "Daniel P. Berrange" <berra...@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@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev