Open Stack

+1 for stashing the stuff into keystoneclient. I presume the 3rd party
contrib policy is applicable to keystoneclient as well?



Guang


-----Original Message-----
From: Adam Young [mailto:ayoung at redhat.com] 
Sent: Monday, November 26, 2012 9:36 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [keystone] Move utils.Ec2Signer class into
keystoneclient?

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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121126/783322f7/attachment.bin>