Development Mailing List \(not for usage questions\)
openstack-dev@lists.openstack.org
Date: 08/19/2015 02:31 PM
Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config
options in nova
Markus Zoeller/Germany/IBM@IBMDE wrote on 08/17/2015 09:37:09 AM:
From: Markus Zoeller
-dev] [openstack][nova] Streamlining of config
options in nova
Michael Still mi...@stillhq.com wrote on 08/12/2015 10:08:26 PM:
From: Michael Still mi...@stillhq.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 08/12
] [openstack][nova] Streamlining of config
options in nova
[...]
Do we see https://review.openstack.org/#/c/205154/ as a reasonable
example of such centralization? If not, what needs to change there to
make it an example of that centralization? I see value in having a
worked
Michael Still mi...@stillhq.com wrote on 08/12/2015 10:08:26 PM:
From: Michael Still mi...@stillhq.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 08/12/2015 10:14 PM
Subject: Re: [openstack-dev] [openstack][nova] Streamlining
On Wed, Aug 12, 2015 at 07:20:24PM +0200, Markus Zoeller wrote:
Another thing which makes it hard to understand the impact of the config
options is, that it's not clear how the interdependency to other config
options is. As an example, the serial_console.base_url has a
dependency to
On 08/13/2015 05:02 AM, Daniel P. Berrange wrote:
On Wed, Aug 12, 2015 at 07:20:24PM +0200, Markus Zoeller wrote:
Another thing which makes it hard to understand the impact of the config
options is, that it's not clear how the interdependency to other config
options is. As an example, the
:35:56 PM:
From: Sean Dague s...@dague.net
To: openstack-dev@lists.openstack.org
Date: 07/27/2015 04:36 PM
Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config
options in nova
On 07/27/2015 10:05 AM, Daniel P. Berrange wrote:
On Fri, Jul 24, 2015 at 09:48:15AM +0100
I think :)
Sean Dague s...@dague.net wrote on 07/27/2015 04:35:56 PM:
From: Sean Dague s...@dague.net
To: openstack-dev@lists.openstack.org
Date: 07/27/2015 04:36 PM
Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config
options in nova
On 07/27/2015 10:05 AM, Daniel P. Berrange
On 08/12/2015 02:23 PM, Jay Pipes wrote:
On 08/12/2015 01:20 PM, Markus Zoeller wrote:
snip
The three questions I have with every config option:
1) which service(s) access this option?
2) what does it do? / what's the impact?
3) which other options do I need to tweek to get the described
On Thu, Aug 13, 2015 at 4:29 AM, Sean Dague s...@dague.net wrote:
On 08/12/2015 02:23 PM, Jay Pipes wrote:
On 08/12/2015 01:20 PM, Markus Zoeller wrote:
snip
The three questions I have with every config option:
1) which service(s) access this option?
2) what does it do? / what's the
On 07/24/2015 02:15 PM, Michael Still wrote:
On Fri, Jul 24, 2015 at 3:55 AM, Daniel P. Berrange berra...@redhat.com
mailto:berra...@redhat.com wrote:
On Thu, Jul 23, 2015 at 11:57:01AM -0500, Michael Still wrote:
In fact, I did an example of what I thought it would look like
On Fri, Jul 24, 2015 at 09:48:15AM +0100, Daniel P. Berrange wrote:
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
During development process in nova I faced with an issue related with config
options. Now we have lists of config options and registering options mixed
On 07/27/2015 10:05 AM, Daniel P. Berrange wrote:
On Fri, Jul 24, 2015 at 09:48:15AM +0100, Daniel P. Berrange wrote:
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
During development process in nova I faced with an issue related with config
options. Now we have lists of
On 07/24/2015 01:48 AM, Daniel P. Berrange wrote:
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
During development process in nova I faced with an issue related with config
options. Now we have lists of config options and registering options mixed
with source code in regular
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
During development process in nova I faced with an issue related with config
options. Now we have lists of config options and registering options mixed
with source code in regular files.
From one side it can be convenient: to
On Thu, Jul 23, 2015 at 11:57:01AM -0500, Michael Still wrote:
In fact, I did an example of what I thought it would look like already:
https://review.openstack.org/#/c/205154/
I welcome discussion on this, especially from people who couldn't make
it to the mid-cycle. Its up to y'all if
Excerpts from Joshua Harlow's message of 2015-07-24 09:07:13 -0700:
Daniel P. Berrange wrote:
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
During development process in nova I faced with an issue related with
config
options. Now we have lists of config options and
Daniel P. Berrange wrote:
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
During development process in nova I faced with an issue related with config
options. Now we have lists of config options and registering options mixed
with source code in regular files.
From one side
Excerpts from Daniel P. Berrange's message of 2015-07-24 15:11:19 +0100:
On Fri, Jul 24, 2015 at 09:56:41AM -0400, Doug Hellmann wrote:
Excerpts from Daniel P. Berrange's message of 2015-07-24 09:48:15 +0100:
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
On Fri, Jul 24, 2015 at 2:19 PM, Doug Hellmann d...@doughellmann.com
wrote:
One idea I've tossed around a bit is having options defined in data
files that ship with the code, rather than being inside the Python
code itself. Maybe a first pass at that would be to offload the
help to a separate
On Fri, Jul 24, 2015 at 09:56:41AM -0400, Doug Hellmann wrote:
Excerpts from Daniel P. Berrange's message of 2015-07-24 09:48:15 +0100:
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
During development process in nova I faced with an issue related with
config
Doug Hellmann wrote:
Excerpts from Joshua Harlow's message of 2015-07-24 09:07:13 -0700:
Daniel P. Berrange wrote:
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
During development process in nova I faced with an issue related with config
options. Now we have lists of
Excerpts from Joshua Harlow's message of 2015-07-24 10:09:10 -0700:
Doug Hellmann wrote:
Excerpts from Joshua Harlow's message of 2015-07-24 09:07:13 -0700:
Daniel P. Berrange wrote:
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
During development process in nova I
On Fri, Jul 24, 2015 at 12:29:56PM -0400, Doug Hellmann wrote:
Excerpts from Joshua Harlow's message of 2015-07-24 09:07:13 -0700:
Daniel P. Berrange wrote:
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
During development process in nova I faced with an issue
Excerpts from Daniel P. Berrange's message of 2015-07-24 09:48:15 +0100:
On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
Hi all,
During development process in nova I faced with an issue related with config
options. Now we have lists of config options and registering options
Excerpts from Michael Still's message of 2015-07-24 13:15:15 -0500:
On Fri, Jul 24, 2015 at 3:55 AM, Daniel P. Berrange berra...@redhat.com
wrote:
On Thu, Jul 23, 2015 at 11:57:01AM -0500, Michael Still wrote:
In fact, I did an example of what I thought it would look like already:
On Fri, Jul 24, 2015 at 3:55 AM, Daniel P. Berrange berra...@redhat.com
wrote:
On Thu, Jul 23, 2015 at 11:57:01AM -0500, Michael Still wrote:
In fact, I did an example of what I thought it would look like already:
https://review.openstack.org/#/c/205154/
I welcome discussion on
nt Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgCc:Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config options in novaDate: Fri, Jul 24, 2015 3:17 PM
On Fri, Jul 24, 2015 at 2:19 PM, Doug Hellmann d...@doughellmann.com wrote:
One idea I've tossed around a b
Sean Dague s...@dague.net wrote on 07/23/2015 01:50:00 PM:
From: Sean Dague s...@dague.net
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 07/23/2015 01:50 PM
Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config
Hi all,
During development process in nova I faced with an issue related with config
options. Now we have lists of config options and registering options mixed
with source code in regular files.
From one side it can be convenient: to have module-encapsulated config
options. But problems appear
On Thu, 2015-07-23 at 17:55 +0300, mhorban wrote:
During development process in nova I faced with an issue related with config
options. Now we have lists of config options and registering options mixed
with source code in regular files.
From one side it can be convenient: to have
In fact, I did an example of what I thought it would look like already:
https://review.openstack.org/#/c/205154/
I welcome discussion on this, especially from people who couldn't make
it to the mid-cycle. Its up to y'all if you do that on this thread or
in that review.
Michael
On Thu, Jul
On 07/23/2015 01:04 PM, Kevin L. Mitchell wrote:
On Thu, 2015-07-23 at 11:41 -0500, Sean Dague wrote:
On 07/23/2015 11:23 AM, Roman Podoliaka wrote:
Hi all,
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]
Putting all Nova options into one big file is probably not a good
On Thu, 2015-07-23 at 13:50 -0500, Sean Dague wrote:
Maybe a directory is fine, especially if module mapped to [subsection].
nova/config/
default.py
glance.py
...
which makes it reasonably discoverable and mappable back and forth from
config file to files.
I like that division
On Thu, 2015-07-23 at 11:41 -0500, Sean Dague wrote:
On 07/23/2015 11:23 AM, Roman Podoliaka wrote:
Hi all,
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]
Putting all Nova options into one big file is probably not a good
idea, still we could consider storing
On 07/23/2015 11:23 AM, Roman Podoliaka wrote:
Hi all,
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]
Putting all Nova options into one big file is probably not a good
idea, still we could consider storing those per-package (per backend,
per driver, etc), rather than
Hi all,
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]
Putting all Nova options into one big file is probably not a good
idea, still we could consider storing those per-package (per backend,
per driver, etc), rather than per Python module to reduce the number
of possible
On 07/23/2015 11:41 AM, Sean Dague wrote:
On 07/23/2015 11:23 AM, Roman Podoliaka wrote:
Hi all,
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]
Putting all Nova options into one big file is probably not a good
idea, still we could consider storing those per-package (per
38 matches
Mail list logo
