On Tue, 2013-06-25 at 09:30 -0600, Pete Zaitcev wrote: > On Tue, 25 Jun 2013 08:50:49 +0100 > Michael Kerrin <[email protected]> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
