-----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 <rakhme...@mirantis.com
> <mailto:rakhme...@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 <d...@stackstorm.com
> <mailto: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
>> <mailto: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
>>> <mailto: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
>>> <mailto:OpenStack-dev@lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> <mailto:OpenStack-dev@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> <mailto:OpenStack-dev@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-----
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
