[openstack-dev] swift & keystone failing in devstack
Chmouel Boudjnah
chmouel at enovance.com
Wed Jun 26 12:59:01 UTC 2013
On Wed, Jun 26, 2013 at 3:18 AM, Jamie Lennox <jlennox at redhat.com> wrote:
> On Tue, 2013年06月25日 at 09:30 -0600, Pete Zaitcev wrote:
>> On 2013年6月25日 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.
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.
More information about the OpenStack-dev
mailing list