Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/05/14 05:00, W Chan wrote:
> Renat,
> 
> I want to avoid having to explicitly import the mistral.config module in order 
> to have configuration loaded properly.  The problem with the way mistral.config 
> is coded is that we have to use importutils otherwise we get pep8 error if we 
> simply insert "from mistral import config".  An example at 
> https://github.com/stackforge/mistral/blob/master/mistral/engine/__init__.py#L29.  This 
> seems to be a chore when it comes down to writing tests where the mistral.config 
> is not necessary loaded (whereas the launch script registers the configuration 
> because the parse_args function in mistral.config is called and the problem 
> isn't as apparent).  So we see the importutils.import_module('mistral.config') 
> scattered in multiple tests.

That is why this exists:

cfg.CONF.import_opt('debug', 'mistral.openstack.common.log')

- -Angus

> 
> My initial patchset has all the configurations under mistral.config but I have 
> them separated into different methods.  The tools/config/generate_sample.sh 
> expects the options to be at top level in the module.  I also looked at a few 
> other OpenStack projects for reference (i.e. nova, ceilometer, oslo.messaging) 
> and then in the latest patchset moved them closer to the modules where they are 
> needed thinking this may be more consistent with other projects.
> 
> I can certainly revisit this and explore an alternate way to keep these config 
> together and avoid the importutils problem.  This may be minor but I want to 
> take care of this clean up before we hit the ground running with juno related bps.
> 
> Winson
> 
> 
> 
> On Thu, May 22, 2014 at 8:29 AM, Renat Akhmerov <rakhmerov at mirantis.com 
> <mailto:rakhmerov at mirantis.com>> wrote:
> 
>     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 <dz at stackstorm.com
>     <mailto:dz at 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.coder at gmail.com
>>     <mailto:m4d.coder at 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.coder at gmail.com
>>>     <mailto:m4d.coder at 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 at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>
>>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>     _______________________________________________
>>     OpenStack-dev mailing list
>>     OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTfqJHAAoJEFrDYBLxZjWoeKYH/16Y6NHQXQyaYOsPUdsqG8Vh
meYRT5hrgdWE/aja41PUyNa6v3eIAy/JaunkK538DKg3xrSNdZZhVXDhmoOxXK1e
3vaClCiPOQlKWhpUlRNTeU+buGqxNLj7mHcEUtWMSn0DDLHd6hNWCFPLIqkQ/nNs
XjO1VIsMn+PNzcsdxF0uXtIr5xH3tjWk2Gv6rjSRqKrvodu+T97B2UNME/s6/kln
y48Rl8iNJm0EBjuySRCtBoMnkuMXJ58jfxEVFo5WpJRJQIEnCWXgiQhRaSwvR5fS
KJB6cbyTd64peMOzgk4pdsr4c/uZKBYFYys//p6WpVzgPJof6CA4S0j2w8jd4ns=
=BVoZ
-----END PGP SIGNATURE-----