Open Stack

Hi Joe,

On Mon, Nov 26, 2012 at 09:21:33AM -0800, 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.

So my use-case is I want to create pre-signed URLs inside the heat
implementation of the AWS WaitConditionHandle resource type:

http://docs.amazonwebservices.com/AWSCloudFormation/latest/UserGuide/aws-properties-waitconditionhandle.html

https://github.com/heat-api/heat/blob/master/heat/engine/resources/wait_condition.py

The idea is that, just like AWS does, we create a pre-signed URL which is
then deployed on the instance, such that we can get WaitCondition event
notification without deploying any credentials on the instance.

The URL would be used to connect from the instance to our Cloudformation API
(which supports ec2 style auth via the keystone ec2 auth extension).

I looked into using boto for this, but their signing implementation is not
exposed as part of their API either, and the code looks much harder to reuse
due to coupling with their internal implementation - the keystone Ec2Signer
class on the other hand looks very easy to reuse :)

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

Yep - I'm going with the assumption that the heat engine will probably not
be deployed on the same box as keystone in real-world environments, so I'd
very much like to avoid any dependency on keystone itself.

Thanks!

Steve