You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by Grig Gheorghiu <gr...@gmail.com> on 2010/09/30 02:00:09 UTC
[libcloud] Re: Adding create_keypair functionality to EC2 driver
Anybody care to comment on this proposal? Or are there better ways to
propose this, via JIRA or something else? This absolute silence is
disquieting for wannabe contributors ;-)
Grig
On Mon, Sep 27, 2010 at 7:41 PM, Grig Gheorghiu
<gr...@gmail.com> wrote:
> Hello,
>
> I took a stab at adding the create_keypair functionality to the
> libcloud EC2 driver. Without this, if you want to launch an EC2
> instance via libcloud, you have to rely on an Amazon EC2 keypair being
> created previously by some other means (otherwise the node gets
> created, but there's no way to ssh into it, unless you take other
> actions via user data).
>
> I am not sure if my first cut at implementing this adheres to the
> libcloud standards. Please see:
>
> http://github.com/griggheo/libcloud/blob/trunk/libcloud/drivers/ec2.py#L361
>
> In particular, I am not very happy with returning a tuple. I am
> thinking a dictionary would be better, or a JSON string. Or even a
> NodeKeypair object. Suggestions are very welcome.
>
> But assuming this method gets implemented, then one would call it to
> retrieve the keypair material, save it at somekey.pem, then call
> node_create and pass ex_keyname='somekey' (assuming 'somekey' is the
> name passed to the method as the keyname). One would then be able to
> ssh into the newly created node by using somekey.pem.
>
> Grig
>
Re: [libcloud] Re: Adding create_keypair functionality to EC2 driver
Posted by Grig Gheorghiu <gr...@gmail.com>.
I don't think a keypair is general enough to apply to the majority of
cloud providers, but it's definitely essential for EC2 operations. The
AWS EC2 API has recently been enhanced with an import-keypair call,
which can take an existing public key and import it into EC2
(create-keypair creates a public key from scratch and stores it on the
EC2 side without the user being able to get to it).
If there's interest, I can look into adding the import-keypair
functionality into the EC2 driver.
My initial question still remains: is the way I implemented that
function correct in terms of return values?
Grig
On Wed, Sep 29, 2010 at 5:49 PM, Eric Woods <wo...@gmail.com> wrote:
> Agreed. My two cents, I think this is an great contribution and highlights the fact that a similar process is needed for most cloud providers.
>
> I'm not familiar with most cloud provider's APIs to manage keys, but if it's widely supported, this could be considered for an extension to the core libcloud API.
>
> Eric W.
>
> On Sep 29, 2010, at 8:00 PM, Grig Gheorghiu wrote:
>
>> Anybody care to comment on this proposal? Or are there better ways to
>> propose this, via JIRA or something else? This absolute silence is
>> disquieting for wannabe contributors ;-)
>>
>> Grig
>>
>> On Mon, Sep 27, 2010 at 7:41 PM, Grig Gheorghiu
>> <gr...@gmail.com> wrote:
>>> Hello,
>>>
>>> I took a stab at adding the create_keypair functionality to the
>>> libcloud EC2 driver. Without this, if you want to launch an EC2
>>> instance via libcloud, you have to rely on an Amazon EC2 keypair being
>>> created previously by some other means (otherwise the node gets
>>> created, but there's no way to ssh into it, unless you take other
>>> actions via user data).
>>>
>>> I am not sure if my first cut at implementing this adheres to the
>>> libcloud standards. Please see:
>>>
>>> http://github.com/griggheo/libcloud/blob/trunk/libcloud/drivers/ec2.py#L361
>>>
>>> In particular, I am not very happy with returning a tuple. I am
>>> thinking a dictionary would be better, or a JSON string. Or even a
>>> NodeKeypair object. Suggestions are very welcome.
>>>
>>> But assuming this method gets implemented, then one would call it to
>>> retrieve the keypair material, save it at somekey.pem, then call
>>> node_create and pass ex_keyname='somekey' (assuming 'somekey' is the
>>> name passed to the method as the keyname). One would then be able to
>>> ssh into the newly created node by using somekey.pem.
>>>
>>> Grig
>>>
>
>
Re: [libcloud] Re: Adding create_keypair functionality to EC2 driver
Posted by Eric Woods <wo...@gmail.com>.
Agreed. My two cents, I think this is an great contribution and highlights the fact that a similar process is needed for most cloud providers.
I'm not familiar with most cloud provider's APIs to manage keys, but if it's widely supported, this could be considered for an extension to the core libcloud API.
Eric W.
On Sep 29, 2010, at 8:00 PM, Grig Gheorghiu wrote:
> Anybody care to comment on this proposal? Or are there better ways to
> propose this, via JIRA or something else? This absolute silence is
> disquieting for wannabe contributors ;-)
>
> Grig
>
> On Mon, Sep 27, 2010 at 7:41 PM, Grig Gheorghiu
> <gr...@gmail.com> wrote:
>> Hello,
>>
>> I took a stab at adding the create_keypair functionality to the
>> libcloud EC2 driver. Without this, if you want to launch an EC2
>> instance via libcloud, you have to rely on an Amazon EC2 keypair being
>> created previously by some other means (otherwise the node gets
>> created, but there's no way to ssh into it, unless you take other
>> actions via user data).
>>
>> I am not sure if my first cut at implementing this adheres to the
>> libcloud standards. Please see:
>>
>> http://github.com/griggheo/libcloud/blob/trunk/libcloud/drivers/ec2.py#L361
>>
>> In particular, I am not very happy with returning a tuple. I am
>> thinking a dictionary would be better, or a JSON string. Or even a
>> NodeKeypair object. Suggestions are very welcome.
>>
>> But assuming this method gets implemented, then one would call it to
>> retrieve the keypair material, save it at somekey.pem, then call
>> node_create and pass ex_keyname='somekey' (assuming 'somekey' is the
>> name passed to the method as the keyname). One would then be able to
>> ssh into the newly created node by using somekey.pem.
>>
>> Grig
>>