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