<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 22, 2013 at 9:11 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Chmoel,<br>
<div><div class="h5"><br>
On Mon, 2013-04-22 at 17:35 +0200, Chmouel Boudjnah wrote:<br>
> Hi,<br>
><br>
> In review :<br>
><br>
> <a href="https://review.openstack.org/#/c/23986/" target="_blank">https://review.openstack.org/#/c/23986/</a><br>
><br>
> I am trying to bring some update to the ec2 token middleware shipped<br>
> with keystone to bring caching, tests use the oslo.config module<br>
> instead of<br>
> nova.flags (which is obsolete in grizzly).<br>
><br>
> When running the tests I am getting the infamous error :<br>
><br>
> 2013-04-18 21:20:55.442 | DuplicateOptError: duplicate option: log-format<br>
><br>
> <a href="http://logs.openstack.org/23986/3/check/gate-keystone-python26-rhel6/219/console.html.gz" target="_blank">http://logs.openstack.org/23986/3/check/gate-keystone-python26-rhel6/219/console.html.gz</a><br>
><br>
> While reading other bug reports on it I understand why this has been<br>
> done, to not get a duplication of config flags, but in my case I just<br>
> have a middleware designed for nova run in keystone and somehow<br>
> oslo.config parse nova and keystone during the tests config flags when<br>
> run by tox.<br>
><br>
> And that's the strange thing when I run the indivual test class the<br>
> problem does not show up but only when I run the full test suite :<br>
><br>
> <a href="http://pastie.org/private/x1wdqcrvrzmlk1h6jkazqg" target="_blank">http://pastie.org/private/x1wdqcrvrzmlk1h6jkazqg</a><br>
><br>
> so I am guessing there is some mix up going on somewhere while runing<br>
> the full test suite.<br>
><br>
><br>
> The solution/workarounds I can see are :<br>
><br>
> 1) Move ec2_token to nova source tree.<br>
> 2) do a try: catch(DuplicateError): pass when parsing the flags.<br>
> 3) Don't use nova for wsgi but the one from keystone.<br>
> 4) fix tox.<br>
><br>
> I don't like 3 because it would assume we need to install keystone<br>
> package to use ec2token middleware which should be used only with nova<br>
> so then i'm in favor of 1) because 2) is just plain ugly and I have<br>
> spent too much time trying to figure out how to do 4) that I am just<br>
> avoiding it (infra peps if you have any ideas?).<br>
<br>
</div></div>I admit I'm replying here without digging into the details, but the<br>
thing that jumps out at me is:<br>
<br>
keystone/middleware/ec2_token.py:<br>
<br>
from nova import wsgi<br>
<br>
tools/test-requires:<br>
<br>
# ec2token test use nova.wsgi<br>
<a href="http://tarballs.openstack.org/nova/nova-master.tar.gz#egg=nova" target="_blank">http://tarballs.openstack.org/nova/nova-master.tar.gz#egg=nova</a><br>
<br>
We really, really should not have code in keystone which depends on code<br>
in nova. Nova is not library code, its interface is not stable.<br>
<br>
Why can't the ec2 token middleware live in Nova?<br></blockquote><div><br></div><div style>or novaclient or keystoneclient, given the precedence of keystoneclient.middleware.auth_token?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
As for the DuplicateOpt error, there are a couple of ways I can see to<br>
avoid it:<br>
<br>
1) Fix it so that importing the ec2 middleware doesn't import all of<br>
keystone's config options via the import in keystone.middleware<br></blockquote><div><br></div><div style>I couldn't find a way to do this when working on <a href="https://bugs.launchpad.net/nova/+bug/1143998">https://bugs.launchpad.net/nova/+bug/1143998</a></div>
<div style><br></div><div style>I ended up implementing a workaround which might work for ec2_token as well? See:</div><div style><br></div><div style> <a href="https://review.openstack.org/#/c/24701/">https://review.openstack.org/#/c/24701/</a><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
or<br>
<br>
2) Make keystone use the common logging infrastructure from Oslo<br></blockquote><div><br></div><div style>+1, but I'd bet that you'd just end up raising a conflict on a different config option?</div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
Mark.<br>
<div class=""><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>