+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
