Open Stack

On 13/06/13 07:09 +0100, Mark McLoughlin wrote:
>On Thu, 2013-06-13 at 13:35 +0800, Zhongyue Luo wrote:
>> So if a file is passed to "generator.py", a module object is created
>> by importing the target file and all attributes in that module
>> object which are oslo.config.cfg.Opt sub-classes or a list of
>> oslo.config.cfg.Opt sub-classes are printed out in the sample config
>> file.
>>
>>
>> Therefore the assumption was that an option will be defined and
>> registered in the same module.
>>
>>
>> However, some projects have options defined and registered on
>> different modules. For instance,
>> https://github.com/openstack/keystone/blob/master/keystone/common/config.py
>>
>>
>> Here, the options are defined but instead of directly registering
>> them, it provides a function which registers the options. And the
>> actual registration happens in,
>> https://github.com/openstack/keystone/blob/master/keystone/config.py#L24
>>
>>
>>
>> Another pattern which is hard to detect the registered options is,
>> https://github.com/openstack/glance/blob/master/glance/cmd/scrubber.py#L54
>>
>>
>>
>> This line is not only registering a option inside a function but the
>> option is also declared inside cfg.register_opt() which is makes it
>> even harder to detect the option.
>>
>>
>> How can we solve this problem of not being able to detect options?
>
>Well, first thing I'd say is that I wouldn't worry about handling every
>possible way of declaring cfg config options.
>
>We can have a convention for how to register config options and a tool
>that supports projects using that convention.
>
>I think we have that now, but keystone chooses not to follow that
>convention ... e.g.
>
>  https://review.openstack.org/4547
>
>I'm pretty sure part of my argument for those keystone changes was that
>the sample config file generator wouldn't work with keystone as it
>stands now.
>
>So, IMHO - any project which doesn't follow the convention should just
>come up with its own custom approach to automating config documentation.
>


Agreed, we won't be able to cover all cases and TBH, we shouldn't.

>> The second option is to make it a convention that all options should
>> be declared in global view and also registered in the same module
>> where they were defined.

-1

At some point, I'd like to see oslo.config going away from globaland.
We can't rely on options being registered globally.

Cheers,
FF

-- 
@flaper87
Flavio Percoco