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
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
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
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
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
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,
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
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
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
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
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
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 =
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
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
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
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
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
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
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
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
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
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 =
22 matches
Mail list logo
