I figured. I implemented it in https://review.openstack.org/#/c/97684/.
On Mon, Jun 16, 2014 at 9:35 PM, Renat Akhmerov rakhme...@mirantis.com
wrote:
I don’t think we have them. You can write them I think as a part of what
you’re doing.
Renat Akhmerov
@ Mirantis Inc.
On 31 May 2014,
Ooh, alright :) It passed by me why I was off.
Renat Akhmerov
@ Mirantis Inc.
On 18 Jun 2014, at 01:20, W Chan m4d.co...@gmail.com wrote:
I figured. I implemented it in https://review.openstack.org/#/c/97684/.
On Mon, Jun 16, 2014 at 9:35 PM, Renat Akhmerov rakhme...@mirantis.com
I don’t think we have them. You can write them I think as a part of what you’re
doing.
Renat Akhmerov
@ Mirantis Inc.
On 31 May 2014, at 04:26, W Chan m4d.co...@gmail.com wrote:
Is there an existing unit test for testing enabling keystone middleware in
pecan (setting
Is there an existing unit test for testing enabling keystone middleware in
pecan (setting cfg.CONF.pecan.auth_enable = True)? I don't seem to find
one. If there's one, it's not obvious. Can someone kindly point me to it?
On Wed, May 28, 2014 at 9:53 AM, W Chan m4d.co...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/05/14 02:48, W Chan 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
On 28 May 2014, at 13:51, Angus Salkeld angus.salk...@rackspace.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/05/14 02:48, W Chan wrote:
Regarding config opts for keystone, the keystoneclient middleware already
registers the opts at
Thanks for following up. I will publish this change as a separate patch
from my current config cleanup.
On Wed, May 28, 2014 at 2:38 AM, Renat Akhmerov rakhme...@mirantis.comwrote:
On 28 May 2014, at 13:51, Angus Salkeld angus.salk...@rackspace.com
wrote:
-BEGIN PGP SIGNED
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
-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
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#L325under
a keystone_authtoken group in the config file. Currently, Mistral
registers the opts
+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
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
12 matches
Mail list logo
