Open Stack

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 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.

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.