I tend to disagree with the whole idea. Not sure 100% though yet. Could you please explain the point of scattering configuration all over the code? In my opinion, we’re mixing different application concerns. With the current approach I always know where to look at in order to find all my configuration option definitions (types, descriptions etc.) but with this refactoring it seems to be a tricky task.
Thoughts? What benefits of doing that? Renat Akhmerov @ Mirantis Inc. On 16 May 2014, at 21:32, Dmitri Zimine <d...@stackstorm.com> wrote: > +1 for breaking down the configuration by modules. > > Not sure about names for configuration group. Do you mean just using the same > group name? or more? > > IMO groups are project specific; it doesn’t always make sense to use the same > group name in the context of different projects. Our requirement is 1) > auto-generate mistral.conf.example from the config.py and 2) sections make > sense in the product context. > > For example: how do we deal with rpc_backend and transport_url for oslo > messaging? Should we do something like CONF.import(_transport_opts, > “oslo.messaging.transport”, “transport”)? And use it by passing the group, > not entire contfig, like: > > transport = messaging.get_transport(cfg.messaging.CONF) > instead of > transport = messaging.get_transport(cfg.CONF) > > DZ> > > > On May 16, 2014, at 12:46 PM, W Chan <m4d.co...@gmail.com> wrote: > >> Regarding config opts for keystone, the keystoneclient middleware already >> registers the opts at >> https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L325 >> under a keystone_authtoken group in the config file. Currently, Mistral >> registers the opts again at >> https://github.com/stackforge/mistral/blob/master/mistral/config.py#L108 >> under a different configuration group. Should we remove the duplicate from >> Mistral and refactor the reference to keystone configurations to the >> keystone_authtoken group? This seems more consistent. >> >> >> On Thu, May 15, 2014 at 1:13 PM, W Chan <m4d.co...@gmail.com> wrote: >> Currently, the various configurations are registered in ./mistral/config.py. >> The configurations are registered when mistral.config is referenced. Given >> the way the code is written, PEP8 throws referenced but not used error if >> mistral.config is referenced but not called in the module. In various use >> cases, this is avoided by using importutils to import mistral.config (i.e. >> https://github.com/stackforge/mistral/blob/master/mistral/tests/unit/engine/test_transport.py#L34). >> I want to break down registration code in ./mistral/config.py into >> separate functions for api, engine, db, etc and move the registration closer >> to the module where the configuration is needed. Any objections? >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
