On Wed, Jun 26, 2013 at 3:18 AM, Jamie Lennox <jlen...@redhat.com> wrote: > On Tue, 2013-06-25 at 09:30 -0600, Pete Zaitcev wrote: >> On Tue, 25 Jun 2013 08:50:49 +0100 >> Michael Kerrin <michael.ker...@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.
and by the way this _happen only_ when swift3 is enabled which is not the default (and s3 api is a best effort support kind of thing). > 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. I am not sure I understand the statement "code from within keystone shouldn't be being used by devstack" >> 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? > I prefer the solution to move to move s3token to swift3 since the two works together and s3token doesn't work without swift3 so it would make sense to move that there. >> - 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. +1, we will need to document this the best way as possible since this could be a pain point for upgrades, I don't think doing a compatibily module (i.e: a dummy module doing a from swift3.s3_token import * in keystone's s3_token) is necessary since swift3 API is a best effort thing IMO but i can be convinced otherwise. Chmouel. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
