Open Stack

On Apr 22, 2013, at 12:33 PM, Chmouel Boudjnah <chmouel at enovance.com> wrote:

> On Mon, Apr 22, 2013 at 7:52 PM, Dolph Mathews <dolph.mathews at gmail.com> wrote:
>>> Why can't the ec2 token middleware live in Nova?
>> or novaclient or keystoneclient, given the precedence of
>> keystoneclient.middleware.auth_token?
> 
> I'd love to move ec2/s3-token to keystoneclient as this is better
> suited there if there is no objections i will send a patch (with a
> compat stub in keystone like it done in auth_token).


Right now the in-use ec2token middleware lives in nova:

https://github.com/openstack/nova/blob/master/nova/api/ec2/__init__.py#L193

This allows us to construct a nova request object directly. The one in
keystone is not used anywhere.

If we move the ec2 middleware into keystone client then we need to store an
intermediate version of the data returned from the authenticate call in the
wsgi env and have a new middleware in nova to turn it into a nova request
object. That seems ok but I don't know if it is a necessary change at this
point.

If the s3 middleware can just end up adding stuff to the wsgi env
and doesn't need internal data then sticking it in keystoneclient makes
sense to me.

Vish

> 
>>>  1) Fix it so that importing the ec2 middleware doesn't import all of
>>>     keystone's config options via the import in keystone.middleware
>> I couldn't find a way to do this when working on
>> https://bugs.launchpad.net/nova/+bug/1143998
>> I ended up implementing a workaround which might work for ec2_token as well?
>> See:
>>  https://review.openstack.org/#/c/24701/
> 
> nice, I may just do that after the move to the ksclient.
> 
> Chmouel.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev