Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Nov 6, 2014, at 7:56 PM, Ian Wienand iwien...@redhat.com 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 11/17/2014 06:57 PM, Vishvananda Ishaya wrote: On Nov 6, 2014, at 7:56 PM, Ian Wienand iwien...@redhat.com 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 7 Nov 2014 16:57, Ian Wienand iwien...@redhat.com 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 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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Nov 4, 2014, at 2:38 PM, melanie witt melwi...@gmail.com wrote: On Nov 4, 2014, at 0:32, Doug Hellmann d...@doughellmann.com 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 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 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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Nov 4, 2014, at 0:32, Doug Hellmann d...@doughellmann.com 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 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. 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
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On 4 November 2014 12:32, Doug Hellmann d...@doughellmann.com 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 rbtcoll...@hp.com 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 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 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...)? [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
[openstack-dev] [nova] pci pass through turing complete config options?
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.
-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
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 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?
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 berra...@redhat.com 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 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?
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 Oct 28, 2014, at 7:34 AM, Sean Dague s...@dague.net 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?
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?
Hi, On 28/10/2014 10:39 AM, Sean Dague wrote: On 10/28/2014 08:31 AM, Daniel P. Berrange wrote: snip 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 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
