Linode API support

4 views
Skip to first unread message

Ryan Tucker

unread,
Aug 4, 2009, 5:57:56 PM8/4/09
to libc...@googlegroups.com
Greetings!

Josh Wright sent over his interface between libcloud and the Python API
bindings, so I've forked cloudkick/libcloud and put them up on github
at:

http://github.com/rtucker/libcloud/tree/master

It's using the reference api.py implementation to avoid reinventing the
wheel too much.

Right now, this patch supports list, reboot, and destroy, but not yet
create (pending further guidance). Let me know what should be done to
make this mergeworthy and I will get it going.

Thanks! -rt

--
Ryan Tucker <rtu...@gmail.com>

signature.asc

Alex Polvi

unread,
Aug 4, 2009, 8:43:24 PM8/4/09
to libc...@googlegroups.com
On Tue, Aug 4, 2009 at 2:57 PM, Ryan Tucker<rtu...@gmail.com> wrote:
> Greetings!
>
> Josh Wright sent over his interface between libcloud and the Python API
> bindings, so I've forked cloudkick/libcloud and put them up on github
> at:
>
> http://github.com/rtucker/libcloud/tree/master

Ryan, awesome!

> It's using the reference api.py implementation to avoid reinventing the
> wheel too much.

This brings up an interesting consideration. Re-inventing the wheel is
indeed a bad thing, but is making a client library of client libraries
worse? I'm not trying to be purest, but we're working really hard to
provide a unified framework so that everything is consistent across
all the supported providers.

I think once we finish up this interface work, it would be good to
take another look at getting this merged in. Which, with this
contribution, needs to happen sooner than later!

Thanks again Ryan,

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

Ryan Tucker

unread,
Aug 5, 2009, 9:01:45 AM8/5/09
to libc...@googlegroups.com
On Tue, 2009-08-04 at 17:43 -0700, Alex Polvi wrote:
> This brings up an interesting consideration. Re-inventing the wheel is
> indeed a bad thing, but is making a client library of client libraries
> worse? I'm not trying to be purest, but we're working really hard to
> provide a unified framework so that everything is consistent across
> all the supported providers.
>
> I think once we finish up this interface work, it would be good to
> take another look at getting this merged in. Which, with this
> contribution, needs to happen sooner than later!

Jed has taken this where I was hoping to end up, and then some, which is
great. So, consider this patch sufficiently superseded!

The original thought was to use a small amount of interface code between
libcloud and the preexisting library, such that changes on either side
could occur without significantly disrupting the other. However, after
thinking about it more, I don't think this is a realistic concern: the
subset of API calls libcloud uses are unlikely to change significantly,
and changes to libcloud's internals would mean nearly uniform changes
across all the drivers.

Thanks for the feedback! -rt

--
Ryan Tucker <rtu...@gmail.com>

signature.asc
Reply all
Reply to author
Forward
0 new messages