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
>>>
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 propose
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
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.co
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
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
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
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:
>
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 separat
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
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 configurin
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=phy
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,produc
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
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 se
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 whi
> 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
li
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 real
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.c
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 ar
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 th
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 MultiStr
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 mus
23 matches
Mail list logo