Initial Concerns

[Tom Davis]

No Tests - This seems like a project that needs good test coverage, given the importance of the API (bringing up servers, dealing with peoples' files, etc.) In fact, there isn't currently any documentation whatsoever (that I can find), not even docstrings! No Common Interface - Everything just inherits from `object` and there's no kind of Interface whatsoever. If you haven't finalized the basic API that's totally fine, e.g. only have `list_nodes` and `get_uuid` or whatever, but it seems like right now there's no way to develop this library in a distributed fashion without ending up with completely conflicting APIs, unless you define some kind of "master driver" that stays ahead of the others, but that's silly. Have you looked into zope.interface (http://pypi.python.org/pypi/zope.interface)? At least by using this, API evolution could be discussed then implemented via the interface -- all implementers would know what is required of their driver. There are other minor things which I could see becoming issues down the road, but these are the two main ones as I see them. Does anyone have an opinion on this stuff?

I like the site, though ;)

[Alex Polvi]

Hi Tom,

Thanks for all the feedback! You're definitely on the right track, and
with your help we'll be able to make this thing awesome.

On Sat, Jul 25, 2009 at 4:05 PM, Tom Davis<t...@dislocatedday.com> wrote:
> No Tests - This seems like a project that needs good test coverage, given
> the importance of the API (bringing up servers, dealing with peoples' files,
> etc.)

I completely agree. Testing web services is pretty difficult, so if
you have any ideas on how to best tackle this, it would add a lot of
value to the project.

We've gotten some basic tests in the test/ directory:

http://github.com/cloudkick/libcloud/tree/bc52bca8dd79a77c3aa1c08bcdf337cba1bfef70/test

Note, there is more work to do here, but the framework is there so you
should be able to TDD your heart out. :)

python setup.py test, to run them

> If you haven't finalized the basic API that's totally fine, e.g. only have
> `list_nodes` and `get_uuid` or whatever, but it seems like right now there's
> no way to develop this library in a distributed fashion without ending up
> with completely conflicting APIs, unless you define some kind of "master
> driver" that stays ahead of the others, but that's silly. Have you looked
> into zope.interface (http://pypi.python.org/pypi/zope.interface)?

Definitely have thought about using the zope.interface stuff, however
I was trying to keep this pure python ... i.e. no external library
dependencies (for python>=2.5). Although, may have to already break
that for JSON support, we'll see.

The plan is to create a "BaseDriver" class which implements the
functions of the API, and each throw "NotImplementedExceptions". From
there, the libraries would inherent from that. Do you think this
satisfies the issue you brought up? I'm planning on adding this soon.

Again, thanks for the feedback.

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

[David Pratt]

Hi Tom. I'd also like to see zope.interface used so that the classes explicitly implement the interfaces defined. It keeps things straight and would be better put in place sooner than later. It is also a great thing for documentation. zope.interface is quite widespread in a variety of python projects. Sometimes the zope namespace scares folks off but this is quite worth the dependency in my view.

Regards,

David

[Tom Davis]

I completely agree. Testing web services is pretty difficult, so if

you have any ideas on how to best tackle this, it would add a lot of

value to the project.

Right now you're using `httplib.Http[s]Connection` (I think this whole thing should be rewritten to be asynchronous, but that's neither here nor there), but if you instead used a library-defined wrapper, such that:

class BaseProvider(object):
    implements(IBaseProvider)
    
    clientCls = libcloud.client.HttpClient

and just overrode `clientCls` on a per-test basis (`HttpTestClientRackspace`, etc.) those could be configured to respond with the proper thing (or something generic for failure if there's no need for a specific error). There are other ways to do this, such as running a local server for testing purposes, but since all you're going to be doing (AFAIK) is issuing GET/POST/PUT/DELETE requests, this would be simple enough to implement in a dummy HTTP client which doesn't actually talk to anything. I can't think of an immediate downside to not implementing a testing network as we are not testing the HTTP client itself.

This would need to conform to the current API versions for each service, assuming they have one (such as Amazon's date-based one) and should probably (in the future) inform a user when they're using an untested API version through a DeprecationWarning, or similarly "kind".

Definitely have thought about using the zope.interface stuff, however
I was trying to keep this pure python ... i.e. no external library
dependencies (for python>=2.5). Although, may have to already break
that for JSON support, we'll see.

With respect, this is a silly goal. Dependencies can be put in the setup file and it's done. For instance, you wouldn't waste time writing a JSON library when suitable libraries already exist, right? So why bother re-implementing interfaces when the Zope folks already have a battle-tested option? Zope.Interface is far more robust than a simple base class which raises NotImplementedException on methods. For instance, you can define (and document) ivars, see if a class implements an interface, get a list of classes which implement an interface (which basically lets you do introspective stuff), etc.

The more code you can bring in from other projects, the less code you need to write. I don't know about you, but I hate writing code I know has already been written for me ;)

[Tom Davis]

Quick follow-up:

The sync/async bit isn't so important, so you can disregard that in any case. Getting end-users to implement proper callbacks and stuff seems a bit extreme, anyway.

But, basically, I feel the goal of all this Interface and base class stuff should be to get the point where adding a new provider doesn't require any significant implementation details to be rewritten. All these providers have REST-ful(ish) interfaces, a default parameter list that needs to be passed for each request, a default return format that you can parse in a predictable way, etc. All of these can be extracted into piece-meal methods that need to be defined by derivative classes. If it is done correctly, we won't even need to use mock HTTP clients because it will just be a matter of, "Okay, if I give `build_base_params` this stuff, it should set these variables to this" and "If I feed this XML to `parse_response` it should return this dictionary (or whatever)".

You've already got the beginnings of this right now, with the whole "XConnection / Response / XProvider" setup, but our first order of business (imo) should be to extract suitable interfaces from these, then implement suitable base classes, THEN (and only then) should we begin working on implementing specific providers.

Thoughts?

[Paul Querna]

On Jul 25, 4:47 pm, Alex Polvi <po...@cloudkick.com> wrote:
> Hi Tom,
>
> Thanks for all the feedback! You're definitely on the right track, and
> with your help we'll be able to make this thing awesome.
>
> On Sat, Jul 25, 2009 at 4:05 PM, Tom Davis<t...@dislocatedday.com> wrote:
> > No Tests - This seems like a project that needs good test coverage, given
> > the importance of the API (bringing up servers, dealing with peoples' files,
> > etc.)
>
> I completely agree. Testing web services is pretty difficult, so if
> you have any ideas on how to best tackle this, it would add a lot of
> value to the project.
>
> We've gotten some basic tests in the test/ directory:
>

> http://github.com/cloudkick/libcloud/tree/bc52bca8dd79a77c3aa1c08bcdf...

>
> Note, there is more work to do here, but the framework is there so you
> should be able to TDD your heart out. :)
>
> python setup.py test, to run them

Aye, but that will only get you so far, since most developers will
only have API keys for 1-2 (more? really?) of the API endpoints.

It seems in the long run, the project should get testing keys for all
API endpoints, and then automatically run the tests over those
endpoints once a day or after every commit to the master The last step
of course is to shutdown all nodes so you don't waste $$ :)

I don't think its something that needs to be done _today_, but in the
long run as more providers are added, there is no way everyone will
have access to test all of them for changes.

Thoughts?

Paul

[Alex Polvi]

I think that's a great idea. I'll try to make it happen.

Another approach, which might also be helpful to API developers
outside of libcloud, could be to create mock service endpoints for
each of these services. gogrid.test.libcloud.org,
rackspace.test.libcloud.org, ec2.test.libcloud.org all have functional
API sandboxes that do not actually manipulate servers. Although,
that'd probably be too much work....

Anyway, I'll try to get a buildbot setup that has some keys in it.

[Alex Polvi]

> [snip]

> Anyway, I'll try to get a buildbot setup that has some keys in it.

Tada! http://build.libcloud.org/waterfall

I'll happily give access to folks after they have contributed a few
patches / gained some level of trust. You can setup github to do a
post push hook, which will cause buildbot to run the test suite
against your tree. Pretty slick! Ping me offlist or freenode
(#cloudkick) if you're interested in getting your repo setup.

-Alex