[openstack-dev] [keystone] Move utils.Ec2Signer class into keystoneclient?

Adam Young ayoung at redhat.com
Mon Nov 26 17:36:05 UTC 2012


On 11/26/2012 12:21 PM, heckj wrote:
> Hey Steve,
>
> Where are you going to make the signed URLs from? Keystoneclient seems like a reasonable place to encapsulate this if you want to import and use from a generic location, but if it's from a different openstack project, it might make more sense to put it into OSLO - for me that just depends on where you're going to use it from and if we can see other projects wanting to do the same thing.
Once we get Oslo as a stand alone library, we can review migrating 
pieces from Keystone to Oslo, but for now, and especially for 
authentication pieces that are Keystone specific (like this) they should 
certainly be in the Keystone client, for the same reason the signing 
code belongs there.



>
> Starting with Keystoneclient seems like a good option to start -avoiding the whole "install keystone to get... X" issue that we ran into with the auth_token middleware.
>
> -joe
>
> On Nov 26, 2012, at 8:45 AM, Adam Young <ayoung at redhat.com> wrote:
>> On 11/26/2012 10:46 AM, Steven Hardy wrote:
>>> Hi,
>>>
>>> I wish to make use of the Ec2Signer class in keystone.common.utils, to
>>> generate pre-signed URLs which are later used for authentication via the
>>> keystone EC2 auth extension.
>>>
>>> I'm obviously keen to avoid directly importing an internal keystone class,
>>> and would prefer to avoid a direct cut/paste, so was considering where it
>>> could be moved such that it's a user-visible utility class?
>>>
>>> Initial thought was that moving the class to either python-keystoneclient or
>>> possibly oslo, wanted to get feedback as to the most acceptable option from
>>> the keystone devs before proceeding?
>>>
>>> My proposal:
>>> - Move Ec2Signer into keystoneclient.utils (or create an authutils module?)
>>> - Make keystone.contrib.ec2.core import Ec2Signer from keystoneclient
>> python-keystoneclient sounds like the right approach.  Please make this a blueprint.
>>
>>
>>> Before spending time generating some patches doing this - would such an
>>> approach be acceptable to the keystone team?
>>>
>>> Thanks!
>>>
>>> Steve
>>>
>>> --
>>> Steve Hardy
>>> Red Hat Engineering, Cloud
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list