Open Stack

On Oct 28, 2014, at 7:34 AM, Sean Dague <sean at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev