Open Stack

On Tue, 2013-06-25 at 09:30 -0600, Pete Zaitcev wrote:
> On Tue, 25 Jun 2013 08:50:49 +0100
> Michael Kerrin <michael.kerrin at hp.com> wrote:
> 
> > we raised a bug https://bugs.launchpad.net/devstack/+bug/1193112 where the 
> 
> > $  /opt/stack/swift/bin/swift-proxy-server /etc/swift/proxy-server.conf -v
> > Traceback (most recent call last):
> >   File "/opt/stack/swift/bin/swift-proxy-server", line 22, in <module>
> >     run_wsgi(conf_file, 'proxy-server', default_port=8080, **options)
> > [.....]
> >   File "/opt/stack/keystone/keystone/middleware/s3_token.py", line 65, in 
> > __init__
> >     self.http_client_class = environment.httplib.HTTPConnection
> > AttributeError: 'NoneType' object has no attribute 'HTTPConnection'
> 
> The issue is that there's no "environment" module in Swift,
> and the s3_token is loaded in the context of Swift's WSGI pipeline.
> 
> > I raised a work around here https://review.openstack.org/#/c/34207/ not in the 
> > hope that this code will get committed but in the hope that someone will see 
> > this and know what to do. That review is also a work around for anyone hit by 
> > this bug.
> > 
> > So if anyone knows what to do for this bug please help,
> 
> The most expedient fix is to undo the part of commit 3afd9791
> which breaks s3_token. I cc-ed Jamie and Adam on it. Actually,
> Michael, since you're the sufferer, why don't you go ahead and
> propose the change instead of 34207? I'll be happy +1 it.

This change was supposed to be a completely keystone internal change and
i didn't realize that it was being used by devstack. Sorry to everyone
who got caught up in it. 

So i've added a review to revert this change regarding middleware held
in the keystone server. https://review.openstack.org/#/c/34484/

In a more general sense code from within keystone shouldn't be being
used by devstack at all and if it needs to be used then i agree that it
should be moved. I've added a new bug
https://bugs.launchpad.net/keystone/+bug/1194688 to track ideas and the
progress of this. 

> Beyond that, we have a few choices:
>  - Add environment to Swift
>    - Either do it like 34207, but that makes Swift depend on Keystone
>      (Michael forgot to adjust requirements.txt, but never mind the
>       small stuff)
>    - Or duck-type environment, like swob

Environment is a way to make transparent whether things are coming from
eventlet or from the stdlib. I'd like to make this a pattern that
everyone implements but it shouldn't be done to fix this bug.

>  - Pull s3_token out of Keystone
>    - Put it into python-keystoneclient, where auth_token already
>      resides. Same environment, same code rules apply. This is going to
>      ruin my webob-destruction party in review 32825, but I'll survive.

This would be the most obvious solution. 

>    - Put it into swift3. I cc-ed Tomo to see if he'd welcome it.
>      The rationale here is that originally s3_token was kept inside
>      Keystone codebase because the protocol between it and the server
>      could change at any minute. Hopefuly this no longer applies
>      and this protocol is going to be a side channel in v3 without
>      any changes. Chmouel?

I would like to see this as it is a niggling pain of mine that keystone
depends upon swift for this middleware. Maybe a way of breaking this
would be to put some s3token functions onto keystoneclient, and make the
middleware use those? 

>    - Put it into Swift, alongside keystoneauth. Not sure about
>      that one.


> I would like to see s3_token migrate to swift3. I'm willing to put
> a couple of patches together to make it happen. Just need Chmouel
> agree that the protocol is stable enough, and Tomo agree, of course.
> 
> -- Pete