merged interfaces: help needed!
Alex Polvi
I just pushed out a major revision to libcloud ... it includes the
interface work that tdavis, jcsalterego, and I have been working on.
Slicehost is now fully supported (create, reboot, destroy, list), and
includes two extra prototype functions (list_images, list_sizes). The
major work of the interface is pretty much complete, but there is
still a lot of room for feedback.
Check it out! http://github.com/cloudkick/libcloud/tree/master
Also, since this is essentially rewriting the driver code, the support
table for libcloud has changed. Right now the only providers supported
are Slicehost, EC-US, and EC2-EU (partially). Releasing early and
often, I had to disable Rackspace, GoGrid and VPS.net to get this code
out. However, they should not be that hard to get running, so if you
want to give it a shot -- that would be a good place to look!
Places we could use help:
* Re-implementing GoGrid and VPS.net (Rackspace is already underway):
this shouldn't be too hard, just look at how
libcloud/drivers/slicehost.py is laid out and move code around to make
it fit
* Testing: Tom added some great MockHttp stuff -- but tests could
alway use more help. We need to validate the requests that are being
generated by the providers. test/test_slicehost.py and
test/test_ec2.py have some good examples on how to go about doing
that.
* Adding more providers: Linode -- we're accepting patches ;)
* Providing feedback on the interfaces -- check out
libcloud/interface.py and libcloud/base.py, let us know where you
think we could add code to make things more flexible
My personal todo list is:
* Write a driver writing doc
* Generate sphinx docs and get them on libcloud.org
* Continue to iterate on create_node, creating is hard to make fit in
a precise box!
Let me know if you decide to undertake any of these tasks! Help would
be greatly appreciated!
Thanks again,
-Alex
--
co-founder, cloudkick.com
twitter.com/cloudkick
541 231 0624
Paul Querna
>
> Hi team,
>
> I just pushed out a major revision to libcloud ... it includes the
> interface work that tdavis, jcsalterego, and I have been working on.
> Slicehost is now fully supported (create, reboot, destroy, list), and
> includes two extra prototype functions (list_images, list_sizes). The
> major work of the interface is pretty much complete, but there is
> still a lot of room for feedback.
>
> Check it out! http://github.com/cloudkick/libcloud/tree/master
>
> Also, since this is essentially rewriting the driver code, the support
> table for libcloud has changed. Right now the only providers supported
> are Slicehost, EC-US, and EC2-EU (partially). Releasing early and
> often, I had to disable Rackspace, GoGrid and VPS.net to get this code
> out. However, they should not be that hard to get running, so if you
> want to give it a shot -- that would be a good place to look!
>
> Places we could use help:
> * Re-implementing GoGrid and VPS.net (Rackspace is already underway):
> this shouldn't be too hard, just look at how
> libcloud/drivers/slicehost.py is laid out and move code around to make
> it fit
Rackspace support for all operations is now up at:
<http://github.com/pquerna/libcloud/tree/master>
Includes MockHttp for everything too!
Biggest difference compared to the others is how Rackspace uses tokens
to get auth, and how it points you at a different server after the
initial auth -- look at the RackspaceConnection._authenticate()
function for the evil details -- thoughts on a better way of doing
this?
If we see more services doing tokens and pointers to other servers, I
suspect we can make a ConnectionUserAndKeyWithToken type class to
generalize it, but for now I think rackspace is the only one with an
authentication API like this?
I really like this interface stuff though, it was a breeze once I got
a handle on how it all works.
Thanks,
Paul
Alex Polvi
>
> On Fri, Aug 7, 2009 at 12:01 AM, Alex Polvi<po...@cloudkick.com> wrote:
>>
>> Hi team,
>>
>> I just pushed out a major revision to libcloud ... it includes the
>> interface work that tdavis, jcsalterego, and I have been working on.
>> Slicehost is now fully supported (create, reboot, destroy, list), and
>> includes two extra prototype functions (list_images, list_sizes). The
>> major work of the interface is pretty much complete, but there is
>> still a lot of room for feedback.
>>
>> Check it out! http://github.com/cloudkick/libcloud/tree/master
>>
>> Also, since this is essentially rewriting the driver code, the support
>> table for libcloud has changed. Right now the only providers supported
>> are Slicehost, EC-US, and EC2-EU (partially). Releasing early and
>> often, I had to disable Rackspace, GoGrid and VPS.net to get this code
>> out. However, they should not be that hard to get running, so if you
>> want to give it a shot -- that would be a good place to look!
>>
>> Places we could use help:
>> * Re-implementing GoGrid and VPS.net (Rackspace is already underway):
>> this shouldn't be too hard, just look at how
>> libcloud/drivers/slicehost.py is laid out and move code around to make
>> it fit
>
> Rackspace support for all operations is now up at:
> <http://github.com/pquerna/libcloud/tree/master>
>
> Includes MockHttp for everything too!
Well done! I should add list_images and list_sizes to the support
table. I've merged it into cloudkick/libcloud.
> Biggest difference compared to the others is how Rackspace uses tokens
> to get auth, and how it points you at a different server after the
> initial auth -- look at the RackspaceConnection._authenticate()
> function for the evil details -- thoughts on a better way of doing
> this?
I'm curious why you did the https and secure check in _authenticate.
Seems like that would be handled by other parts of the API.
> If we see more services doing tokens and pointers to other servers, I
> suspect we can make a ConnectionUserAndKeyWithToken type class to
> generalize it, but for now I think rackspace is the only one with an
> authentication API like this?
I'm pretty sure they are the only ones that do it this way. In the
end, it does boil down to username and password, so I think using
ConnectionUserAndKey makes perfect sense. I'm glad you were able to
figure out a way to make it work with the interface.
> I really like this interface stuff though, it was a breeze once I got
> a handle on how it all works.
Seriously, mad props to tdavis for all the heavy lifting on the interfaces! :)