Re: [openstack-dev] [nova] pci pass through turing complete config options?
On 11/17/2014 06:57 PM, Vishvananda Ishaya wrote: > > On Nov 6, 2014, at 7:56 PM, Ian Wienand wrote: > >> On 10/29/2014 12:42 AM, Doug Hellmann wrote: >>> Another way to do this, which has been used in some other projects, >>> is to define one option for a list of “names” of things, and use >>> those names to make groups with each field >> >> I've proposed that in [1]. I look forward to some -1's :) >> >>> OTOH, oslo.config is not the only way we have to support >>> configuration. This looks like a good example of settings that are >>> more complex than what oslo.config is meant to handle, and that >>> might be better served in a separate file with the location of that >>> file specified in an oslo.config option. >> >> My personal opinion is that yet-another-config-file in possibly >> yet-another-format is just a few lines of code, but has a pretty high >> cost for packagers, testers, admins, etc. So I feel like that's >> probably a last-resort. > > In most discussions I’ve had with deployers, the prefer multiple files, as it > is easier to create a new file via puppet or chef when a feature is turned > on than to add a bunch of new sections in the middle of an existing file. +1 -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Nov 6, 2014, at 7:56 PM, Ian Wienand wrote: > On 10/29/2014 12:42 AM, Doug Hellmann wrote: >> Another way to do this, which has been used in some other projects, >> is to define one option for a list of “names” of things, and use >> those names to make groups with each field > > I've proposed that in [1]. I look forward to some -1's :) > >> OTOH, oslo.config is not the only way we have to support >> configuration. This looks like a good example of settings that are >> more complex than what oslo.config is meant to handle, and that >> might be better served in a separate file with the location of that >> file specified in an oslo.config option. > > My personal opinion is that yet-another-config-file in possibly > yet-another-format is just a few lines of code, but has a pretty high > cost for packagers, testers, admins, etc. So I feel like that's > probably a last-resort. In most discussions I’ve had with deployers, the prefer multiple files, as it is easier to create a new file via puppet or chef when a feature is turned on than to add a bunch of new sections in the middle of an existing file. Vish > > -i > > [1] https://review.openstack.org/133138 > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On 7 Nov 2014 16:57, "Ian Wienand" wrote: > > On 10/29/2014 12:42 AM, Doug Hellmann wrote: >> >> Another way to do this, which has been used in some other projects, >> is to define one option for a list of “names” of things, and use >> those names to make groups with each field > > > I've proposed that in [1]. I look forward to some -1's :) > > >> OTOH, oslo.config is not the only way we have to support >> configuration. This looks like a good example of settings that are >> more complex than what oslo.config is meant to handle, and that >> might be better served in a separate file with the location of that >> file specified in an oslo.config option. > > > My personal opinion is that yet-another-config-file in possibly > yet-another-format is just a few lines of code, but has a pretty high > cost for packagers, testers, admins, etc. So I feel like that's > probably a last-resort. Mangling hardware data into an obtuse format is harder than it needs to be. Dropping a new file in /etc is very ready for a deployer. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On 10/29/2014 12:42 AM, Doug Hellmann wrote: Another way to do this, which has been used in some other projects, is to define one option for a list of “names” of things, and use those names to make groups with each field I've proposed that in [1]. I look forward to some -1's :) OTOH, oslo.config is not the only way we have to support configuration. This looks like a good example of settings that are more complex than what oslo.config is meant to handle, and that might be better served in a separate file with the location of that file specified in an oslo.config option. My personal opinion is that yet-another-config-file in possibly yet-another-format is just a few lines of code, but has a pretty high cost for packagers, testers, admins, etc. So I feel like that's probably a last-resort. -i [1] https://review.openstack.org/133138 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Nov 4, 2014, at 2:38 PM, melanie witt wrote: > On Nov 4, 2014, at 0:32, Doug Hellmann wrote: > I think this is reasonable, though do we actually support setting the same key twice ? >> >> Yes, if it is registered in different groups. > > I have found that for a MultiStrOpt, the same key can be set multiple times > even in the same group, and the result is a list of values for that option > [0]. Yes, that’s the purpose of MultiStrOpt. However, it is meant to hold a list of related items, not a list of instances of values that are essentially attributes of unrelated objects. If you have more than one property for a PCI passthrough device, you will need a separate MultiStrOpt for each one. The user will then have to ensure that they specify their options and values in order within their configuration file so that the separate arrays are populated consistently so the values in position 0 are all related and the values in position 1 are all related, etc. That is much more error prone then defining new groups and taking advantage of the syntax of the configuration file to help the user understand that a block of options is all related. Now, all of that said, I still think you should just use a YAML file for this data. Doug > > [0] > https://github.com/openstack/oslo.config/blob/11ecf18/oslo/config/cfg.py#L1011 > ___ > 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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Nov 4, 2014, at 2:07 PM, Robert Li (baoli) wrote: > > > On 11/3/14, 6:32 PM, "Doug Hellmann" wrote: > >> >> On Oct 31, 2014, at 9:27 PM, Robert Li (baoli) wrote: >> >>> >>> >>> On 10/28/14, 11:01 AM, "Daniel P. Berrange" 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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Nov 4, 2014, at 0:32, Doug Hellmann wrote: >>> I think this is reasonable, though do we actually support setting >>> the same key twice ? > > Yes, if it is registered in different groups. I have found that for a MultiStrOpt, the same key can be set multiple times even in the same group, and the result is a list of values for that option [0]. [0] https://github.com/openstack/oslo.config/blob/11ecf18/oslo/config/cfg.py#L1011 signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On 11/3/14, 6:32 PM, "Doug Hellmann" wrote: > >On Oct 31, 2014, at 9:27 PM, Robert Li (baoli) wrote: > >> >> >> On 10/28/14, 11:01 AM, "Daniel P. Berrange" 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 hav
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On 4 November 2014 12:32, Doug Hellmann wrote: > ... > 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 And the use of an int as a name. Personally I think a separate yaml file would be a bit nicer. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Oct 31, 2014, at 9:27 PM, Robert Li (baoli) wrote: > > > On 10/28/14, 11:01 AM, "Daniel P. Berrange" 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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Fri, Oct 31, 2014 at 08:27:24PM +, Robert Li (baoli) wrote: > Without direct oslo support, to implement it requires a small method that > uses oslo cfg¹s MultiConfigParser(). > > 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. Yes, backwards compatibility is mandatory. If we want to get rid of the old format you need to have 1 release cycle where it is issuing a deprecation warning. So the L release would be first place it cna be deleted entirely > ‹ 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. Just use a different name for the new config option to avoid confusion between old & new syntax. 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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On 10/28/14, 11:01 AM, "Daniel P. Berrange" 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...)? >> >> [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 ? > >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 > 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(). 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. ‹ 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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
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...)? > > [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 ? 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 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 > 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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
Hi, On 28/10/2014 10:39 AM, Sean Dague wrote: On 10/28/2014 08:31 AM, Daniel P. Berrange wrote: I don't think that is really very extensible for the future to drop the key name. We've already extended the info we record here at least once, and I expect we'd want to add more fields later. It is also makes it less clear to the user - it is very easy to get confused about vendor vs product IDs if we leave out the name. If we really need that level of arbitrary complexity and future name values we should then just: pci_passthrough_cfg = /etc/nova/pci_pass.yaml And build fully nested structures over there. Doing multi level nesting inside of .ini format files is just kind of gross. -Sean The PCI whitelist mechanism needs to be extensible and for the sake of expediency the existing whitelist mechanism was modified to add the fields it has now. There has been discussion that the current mechanism is either insufficient or simply completely undesirable for the PCI passthrough use cases and the current approach was an interim solution. Unless the current situation is completely untenable and simply must go, is this a good opportunity to revisit previous discussions and proposals before devising alternatives? Cheers, Brent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
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...)? [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 Either that, or the YAML file that Sean suggested, would be my preference... Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Oct 28, 2014, at 7:34 AM, Sean Dague wrote: > We're dealing with some issues on devstack pass through with really > complicated config option types, the fixes are breaking other things. > > The issue at hand is the fact that the pci pass through device listing > is an olso MultiStrOpt in which each option value is fully valid json > document, which must parse as such. That leads to things like: > > pci_passthrough_whitelist = {"address":"*:0a:00.*", > "physical_network":"physnet1"} > pci_passthrough_whitelist = {"vendor_id":"1137","product_id":"0071"} > > Which, honestly, seems a little weird for configs. > > We're talking about a small number of fixed fields here, so the use of a > full json doc seems weird. I'd like to reopen why this was the value > format, and if we could have a more simple one. > > We're probably going to revert the attempted devstack support for pass > through of these things anyway, because it's breaking variable > interpolation in other config options. And the complexity added by > trying to add support for things like that in local.conf has shown to be > too much for the current ini parser structure. Another way to do this, which has been used in some other projects, is to define one option for a list of “names” of things, and use those names to make groups with each field in an individual option. This similar to the logging config file. For example, [DEFAULT] pci_passthrough_rules = by_address, by_vendor_id [pci_passthrough_by_address] address = *:0a:00.* physical_network = physnet1 [pci_passthrough_by_vendor_id] vendor_id 1137 product_id 0071 The options for each “pci_passthrough_*” group can be registered multiple times as long as the group name is different. You would access the values as cfg.CONF.pci_passthrough_by_address.address, etc., and that places some naming restrictions on the groups. OTOH, oslo.config is not the only way we have to support configuration. This looks like a good example of settings that are more complex than what oslo.config is meant to handle, and that might be better served in a separate file with the location of that file specified in an oslo.config option. Doug > > -Sean > > -- > Sean Dague > http://dague.net > > ___ > 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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
> If we really need that level of arbitrary complexity and future name > values we should then just: > > pci_passthrough_cfg = /etc/nova/pci_pass.yaml I hate to have to introduce a new thing like that, but I also think that JSON-encoded config variable strings are a nightmare. They lead to bugs like this: https://bugs.launchpad.net/nova/+bug/1383345 So I'd rather see something that is a little easier to manage. Also, moving things like this out to a separate file makes it easy to generate/update that file automatically, which is probably a useful thing for something like PCI. --Dan signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On 10/28/2014 08:31 AM, Daniel P. Berrange wrote: > On Tue, Oct 28, 2014 at 08:07:14AM -0400, Sean Dague wrote: >> On 10/28/2014 07:44 AM, Daniel P. Berrange wrote: >>> On Tue, Oct 28, 2014 at 07:34:11AM -0400, Sean Dague wrote: We're dealing with some issues on devstack pass through with really complicated config option types, the fixes are breaking other things. The issue at hand is the fact that the pci pass through device listing is an olso MultiStrOpt in which each option value is fully valid json document, which must parse as such. That leads to things like: pci_passthrough_whitelist = {"address":"*:0a:00.*", "physical_network":"physnet1"} pci_passthrough_whitelist = {"vendor_id":"1137","product_id":"0071"} Which, honestly, seems a little weird for configs. We're talking about a small number of fixed fields here, so the use of a full json doc seems weird. I'd like to reopen why this was the value format, and if we could have a more simple one. >>> >>> Do you have ant suggestion for an alternative config syntax for specifying >>> a list of dicts which would be suitable ? >>> >>> 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 >>> >>> Overall it isn't clear that inventing a special case language for this PCI >>> config value is a good idea. >>> >>> I think it illustrates a gap in oslo.config, which ought to be able to >>> support a config option type which was a "list of dicts of strings" >>> so anywhere which needs such a beast will use the same syntax. >> >> Mostly, why do we need name= at all. This seems like it would be fine as >> an fstab like format (with 'x' as an ignore value). >> >> # vendor_id product_id address >> pci_passthrough_whitelist = 8085 >> pci_passthrough_whitelist = 1137 4fc2 >> pci_passthrough_whitelist = x 0071 >> pci_passthrough_whitelist = x x *0a:00.* >> >> Basically going to a full name = value seems incredibly overkill for >> something with < 6 fields. > > I don't think that is really very extensible for the future to drop the > key name. We've already extended the info we record here at least once, > and I expect we'd want to add more fields later. It is also makes it > less clear to the user - it is very easy to get confused about vendor > vs product IDs if we leave out the name. If we really need that level of arbitrary complexity and future name values we should then just: pci_passthrough_cfg = /etc/nova/pci_pass.yaml And build fully nested structures over there. Doing multi level nesting inside of .ini format files is just kind of gross. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
Sean, Are you talking about this one: https://review.openstack.org/#/c/128805/? is it still breaking something after fixing the incompatible awk syntax? Originally https://review.openstack.org/#/c/123599/ proposed a simple patch to support that config. But it was abandoned in favor of the local.conf meta-section. Thanks, Robert On 10/28/14, 8:31 AM, "Daniel P. Berrange" wrote: >On Tue, Oct 28, 2014 at 08:07:14AM -0400, Sean Dague wrote: >> On 10/28/2014 07:44 AM, Daniel P. Berrange wrote: >> > On Tue, Oct 28, 2014 at 07:34:11AM -0400, Sean Dague wrote: >> >> We're dealing with some issues on devstack pass through with really >> >> complicated config option types, the fixes are breaking other things. >> >> >> >> The issue at hand is the fact that the pci pass through device >>listing >> >> is an olso MultiStrOpt in which each option value is fully valid json >> >> document, which must parse as such. That leads to things like: >> >> >> >> pci_passthrough_whitelist = {"address":"*:0a:00.*", >> >> "physical_network":"physnet1"} >> >> pci_passthrough_whitelist = {"vendor_id":"1137","product_id":"0071"} >> >> >> >> Which, honestly, seems a little weird for configs. >> >> >> >> We're talking about a small number of fixed fields here, so the use >>of a >> >> full json doc seems weird. I'd like to reopen why this was the value >> >> format, and if we could have a more simple one. >> > >> > Do you have ant suggestion for an alternative config syntax for >>specifying >> > a list of dicts which would be suitable ? >> > >> > 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 >> > >> > Overall it isn't clear that inventing a special case language for >>this PCI >> > config value is a good idea. >> > >> > I think it illustrates a gap in oslo.config, which ought to be able to >> > support a config option type which was a "list of dicts of strings" >> > so anywhere which needs such a beast will use the same syntax. >> >> Mostly, why do we need name= at all. This seems like it would be fine as >> an fstab like format (with 'x' as an ignore value). >> >> # vendor_id product_id address >> pci_passthrough_whitelist = 8085 >> pci_passthrough_whitelist = 1137 4fc2 >> pci_passthrough_whitelist = x 0071 >> pci_passthrough_whitelist = x x *0a:00.* >> >> Basically going to a full name = value seems incredibly overkill for >> something with < 6 fields. > >I don't think that is really very extensible for the future to drop the >key name. We've already extended the info we record here at least once, >and I expect we'd want to add more fields later. It is also makes it >less clear to the user - it is very easy to get confused about vendor >vs product IDs if we leave out the name. > >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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Tue, Oct 28, 2014 at 08:07:14AM -0400, Sean Dague wrote: > On 10/28/2014 07:44 AM, Daniel P. Berrange wrote: > > On Tue, Oct 28, 2014 at 07:34:11AM -0400, Sean Dague wrote: > >> We're dealing with some issues on devstack pass through with really > >> complicated config option types, the fixes are breaking other things. > >> > >> The issue at hand is the fact that the pci pass through device listing > >> is an olso MultiStrOpt in which each option value is fully valid json > >> document, which must parse as such. That leads to things like: > >> > >> pci_passthrough_whitelist = {"address":"*:0a:00.*", > >> "physical_network":"physnet1"} > >> pci_passthrough_whitelist = {"vendor_id":"1137","product_id":"0071"} > >> > >> Which, honestly, seems a little weird for configs. > >> > >> We're talking about a small number of fixed fields here, so the use of a > >> full json doc seems weird. I'd like to reopen why this was the value > >> format, and if we could have a more simple one. > > > > Do you have ant suggestion for an alternative config syntax for specifying > > a list of dicts which would be suitable ? > > > > 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 > > > > Overall it isn't clear that inventing a special case language for this PCI > > config value is a good idea. > > > > I think it illustrates a gap in oslo.config, which ought to be able to > > support a config option type which was a "list of dicts of strings" > > so anywhere which needs such a beast will use the same syntax. > > Mostly, why do we need name= at all. This seems like it would be fine as > an fstab like format (with 'x' as an ignore value). > > # vendor_id product_id address > pci_passthrough_whitelist = 8085 > pci_passthrough_whitelist = 1137 4fc2 > pci_passthrough_whitelist = x 0071 > pci_passthrough_whitelist = x x *0a:00.* > > Basically going to a full name = value seems incredibly overkill for > something with < 6 fields. I don't think that is really very extensible for the future to drop the key name. We've already extended the info we record here at least once, and I expect we'd want to add more fields later. It is also makes it less clear to the user - it is very easy to get confused about vendor vs product IDs if we leave out the name. 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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On 10/28/2014 07:44 AM, Daniel P. Berrange wrote: > On Tue, Oct 28, 2014 at 07:34:11AM -0400, Sean Dague wrote: >> We're dealing with some issues on devstack pass through with really >> complicated config option types, the fixes are breaking other things. >> >> The issue at hand is the fact that the pci pass through device listing >> is an olso MultiStrOpt in which each option value is fully valid json >> document, which must parse as such. That leads to things like: >> >> pci_passthrough_whitelist = {"address":"*:0a:00.*", >> "physical_network":"physnet1"} >> pci_passthrough_whitelist = {"vendor_id":"1137","product_id":"0071"} >> >> Which, honestly, seems a little weird for configs. >> >> We're talking about a small number of fixed fields here, so the use of a >> full json doc seems weird. I'd like to reopen why this was the value >> format, and if we could have a more simple one. > > Do you have ant suggestion for an alternative config syntax for specifying > a list of dicts which would be suitable ? > > 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 > > Overall it isn't clear that inventing a special case language for this PCI > config value is a good idea. > > I think it illustrates a gap in oslo.config, which ought to be able to > support a config option type which was a "list of dicts of strings" > so anywhere which needs such a beast will use the same syntax. Mostly, why do we need name= at all. This seems like it would be fine as an fstab like format (with 'x' as an ignore value). # vendor_id product_id address pci_passthrough_whitelist = 8085 pci_passthrough_whitelist = 1137 4fc2 pci_passthrough_whitelist = x 0071 pci_passthrough_whitelist = x x *0a:00.* Basically going to a full name = value seems incredibly overkill for something with < 6 fields. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Tue, Oct 28, 2014 at 07:34:11AM -0400, Sean Dague wrote: > We're dealing with some issues on devstack pass through with really > complicated config option types, the fixes are breaking other things. > > The issue at hand is the fact that the pci pass through device listing > is an olso MultiStrOpt in which each option value is fully valid json > document, which must parse as such. That leads to things like: > > pci_passthrough_whitelist = {"address":"*:0a:00.*", > "physical_network":"physnet1"} > pci_passthrough_whitelist = {"vendor_id":"1137","product_id":"0071"} > > Which, honestly, seems a little weird for configs. > > We're talking about a small number of fixed fields here, so the use of a > full json doc seems weird. I'd like to reopen why this was the value > format, and if we could have a more simple one. Do you have ant suggestion for an alternative config syntax for specifying a list of dicts which would be suitable ? 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 Overall it isn't clear that inventing a special case language for this PCI config value is a good idea. I think it illustrates a gap in oslo.config, which ought to be able to support a config option type which was a "list of dicts of strings" so anywhere which needs such a beast will use the same syntax. 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