[openstack-dev] [oslo] Option registration convention?
Flavio Percoco
flavio at redhat.com
Thu Jun 13 07:17:36 UTC 2013
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
More information about the OpenStack-dev
mailing list