[PULL REQUEST] EC2 support for list_sizes, list_images, and create_node.

[oremj]

Hey, requesting a pull. I've implemented the remaining methods for
EC2. One oddity, Amazon provides no way of dynamically listing
"sizes", so I had to hard code them. Let me know what you think.
Thanks.

---
The following changes since commit
2164cd41be6c64521800c4935daaed3b2e9c88cc:
Alex Polvi (1):
update to contrib file

are available in the git repository at:

git://github.com/oremj/libcloud.git master

Jeremy Orem (3):
Add list_sizes method to ec2.
Add list_images method to ec2.
Added create_node support for EC2.

CONTRIBUTORS | 2 +-
libcloud/drivers/ec2.py | 70 +++++++++++++++++++++++++++++++++++++++
+++-
test/test_ec2.py | 77 +++++++++++++++++++++++++++++++++++++++
+++++++-
3 files changed, 146 insertions(+), 3 deletions(-)

[Alex Polvi]

Hey Jeremy,

Good patch! With test cases too, nice work. I've gone ahead and merged it, as it does add support.Few suggestions, if possible: In create_node, mincount, maxcount, keyname, and security group should all optionally come from the kwargs. If they are not in the kwargs, default them to 1, 1, None, None, respectively. Also, it would be great to do the same for list images, so you could set owner and user. Similar to how this tool works: http://docs.amazonwebservices.com/AmazonEC2/dg/2006-10-01/CLTRG-describe-images.html

Again, I'm just thinking do something like: owner = kwargs.get('owner', None), if owner: ...

Thanks again!

-Alex

--
co-founder, cloudkick.com
twitter.com/cloudkick
541 231 0624

[Jeremy Orem]

The following changes since commit

883d7ee9865dce4c575d3e5b725bf4fdd24230c0:
Jeremy Orem (1):

Added create_node support for EC2.

are available in the git repository at:

git://github.com/oremj/libcloud.git master

Jeremy Orem (1):
Adds optional arguments to create_node and list_images.

libcloud/drivers/ec2.py | 33 ++++++++++++++++++++++++---------
1 files changed, 24 insertions(+), 9 deletions(-)

On Sep 19, 1:01 pm, Alex Polvi <po...@cloudkick.com> wrote:
> Hey Jeremy,
>
> Good patch! With test cases too, nice work. I've gone ahead and merged it,
> as it does add support.Few suggestions, if possible: In create_node,
> mincount, maxcount, keyname, and security group should all optionally come
> from the kwargs. If they are not in the kwargs, default them to 1, 1, None,
> None, respectively. Also, it would be great to do the same for list images,

> so you could set owner and user. Similar to how this tool works:http://docs.amazonwebservices.com/AmazonEC2/dg/2006-10-01/CLTRG-descr...

[Alex Polvi]

Hmm, this raises an interesting question. The interface for list_images says it takes no arguments, so our options are:

1) update the entire interface, so you can send kwargs to and driver
2) do not allow kwargs and just have a default behavior for each provider

Anyone have any comment on why we should go one way or another? I'm kind of leaning towards #1, just to add more flexibility. However, then we have to ask why not just add kwargs to all functions of the interface as a way to pass provider specific detail.

-Alex

[Jeremy Orem]

#1 seems like the best option to me, since it will allow us to tap in
to more advanced functionality of some APIs. I'm new to the project,
however, so I may be overlooking something.

[Alex Polvi]

Hi,

I'm a little nervous adding this to the interface. I think the best plan of action, for now, is just have create_node support the kwargs stuff. list_images will just support listing everything the provider has for now. Sorry to ask you to do something then change my mind! If others think this is the wrong approach, I'm totally open to feedback.

-Alex

[Jed Smith]

No, you're right. Eventually the interface has to be frozen
completely, otherwise keeping the driver updated will become a lot
more work than it should be.

Allowing provider-specific kwargs -- outside of create_node, I think
that's where it's most useful -- takes away from the homogenous
platform aspect of libcloud somewhat. Eventually, it'd become the
library of provider-specific exceptions...which was sort of the
initial problem to solve, no?

Regards,
Jed

[Jeremy Orem]

I've backed out the list_sizes changes.

The following changes since commit 883d7ee9865dce4c575d3e5b725bf4fdd24230c0:
  Jeremy Orem (1):
        Added create_node support for EC2.

are available in the git repository at:

  git://github.com/oremj/libcloud.git master

Jeremy Orem (1):

      Adds optional arguments to create_node.

 libcloud/drivers/ec2.py |   24 ++++++++++++++++--------
 1 files changed, 16 insertions(+), 8 deletions(-)

[Alex Polvi]

Thank you, merged and pushed!

-Alex

[Alex Polvi]

Jeremy,

Just noticed something. The prices of EC2 EU are different than that of EC2 US. Probably need to override the list_sizes function and provide different responses.

See "Pricing" table on this page:

http://aws.amazon.com/ec2/

-Alex

[Jeremy Orem]

Good catch. I'll fix that right away.

[Jeremy Orem]

The following changes since commit

e59d02265343527eb49e30aac87d186035b6f691:

Jeremy Orem (1):
Adds optional arguments to create_node.

are available in the git repository at:

git://github.com/oremj/libcloud.git master

Jeremy Orem (1):

Different EC2 prices for US and EU.

libcloud/drivers/ec2.py | 46 +++++++++++++++++++++++++++++
+----------------
test/test_ec2.py | 4 +++-
2 files changed, 33 insertions(+), 17 deletions(-)

On Sep 21, 3:56 pm, Jeremy Orem <jeremy.o...@gmail.com> wrote:
> Good catch. I'll fix that right away.
>
> On Mon, Sep 21, 2009 at 3:54 PM, Alex Polvi <po...@cloudkick.com> wrote:
> > Jeremy,
>
> > Just noticed something. The prices of EC2 EU are different than that of EC2
> > US. Probably need to override the list_sizes function and provide different
> > responses.
>
> > See "Pricing" table on this page:
>
> >http://aws.amazon.com/ec2/
>
> > -Alex
>
> > On Mon, Sep 21, 2009 at 11:19 AM, Alex Polvi <po...@cloudkick.com> wrote:
>
> >> Thank you, merged and pushed!
>
> >> -Alex
>

> >> On Mon, Sep 21, 2009 at 11:14 AM, Jeremy Orem <jeremy.o...@gmail.com>

> >>>> > On Sat, Sep 19, 2009 at 3:24 PM, Jeremy Orem <jeremy.o...@gmail.com>