Mark -
> I don't think I've seen code (except for obscure cases) which uses the
> CONF global directly (as opposed to being passed CONF as a parameter)
> but doesn't register the options at import time.
>
> Mark.
>
>
Keystone uses the CONF global directly and doesn't register the options at
impor
On Tue, 2014-08-26 at 10:00 -0400, Doug Hellmann wrote:
> On Aug 26, 2014, at 6:30 AM, Mark McLoughlin wrote:
>
> > On Mon, 2014-08-11 at 15:06 -0400, Doug Hellmann wrote:
> >> On Aug 8, 2014, at 7:22 PM, Devananda van der Veen
> >> wrote:
> >>
> >>> On Fri, Aug 8, 2014 at 12:41 PM, Doug Hellm
On Aug 26, 2014, at 6:30 AM, Mark McLoughlin wrote:
> On Mon, 2014-08-11 at 15:06 -0400, Doug Hellmann wrote:
>> On Aug 8, 2014, at 7:22 PM, Devananda van der Veen
>> wrote:
>>
>>> On Fri, Aug 8, 2014 at 12:41 PM, Doug Hellmann
>>> wrote:
That’s right. The preferred approach is t
On Mon, 2014-08-11 at 15:06 -0400, Doug Hellmann wrote:
> On Aug 8, 2014, at 7:22 PM, Devananda van der Veen
> wrote:
>
> > On Fri, Aug 8, 2014 at 12:41 PM, Doug Hellmann
> > wrote:
> >>
> >> That’s right. The preferred approach is to put the register_opt() in
> >> *runtime* code somewhere be
On Aug 8, 2014, at 7:22 PM, Devananda van der Veen
wrote:
> On Fri, Aug 8, 2014 at 12:41 PM, Doug Hellmann wrote:
>>
>> That’s right. The preferred approach is to put the register_opt() in
>> *runtime* code somewhere before the option will be used. That might be in
>> the constructor for a cl
On Fri, Aug 8, 2014 at 12:41 PM, Doug Hellmann wrote:
>
> That’s right. The preferred approach is to put the register_opt() in
> *runtime* code somewhere before the option will be used. That might be in
> the constructor for a class that uses an option, for example, as described
> in
> http://docs
On Aug 8, 2014, at 1:30 PM, Vishvananda Ishaya wrote:
> Hi Alistair,
>
> Modules can register their own options and there is no need to call
> reload_config_files. The config files are parsed and values stored in case
> the option is later declared. The only time you need to reload files is i
Hi Alistair,
Modules can register their own options and there is no need to call
reload_config_files. The config files are parsed and values stored in case the
option is later declared. The only time you need to reload files is if you add
new config files in the new module. See the example code
I've been looking at the implications of applying oslo.config in Swift, and I
have a question about the best pattern for registering options.
Looking at how keystone uses oslo.config, the pattern seems to be to have all
options declared and registered 'up-front' in a single place
(keystone/comm
