On Thu, Dec 10, 2009 at 2:28 AM, Alex Polvi <[email protected]> wrote: > What things do we need to get fixed before we cut an initial release?
I'd like to see better debugging support. Maybe I'm biased because having just started to use libcloud I'm debugging a bunch of stuff (a little in libcloud, more in my own code or the upstream API). Another concern I have is that many methods take objects, and can't take something like IDs. E.g., if you want to destroy a node, you need the node object. To get that, you do a query. But given an identifier, the underlying API doesn't need an "object" just that identifier. A more concrete example, actually; I want to create servers mostly from the same image. I'd like to just save that image ID in a configuration file, and create it from there. With the current API I save the image ID, do driver.list_images(), match those results against that ID, and then do driver.create_node(). (I could probably pickle the image object, but I'm just using a text configuration file so a pickle would be awkward.) > Some of the things on my list are: > > * Consistent exceptions across the drivers. There should be a base > ProviderException that gets inherited by each provider implementation. > We also need a standard set of exceptions to handle common errors > (InvalidCredentials comes to mind). Do providers need their own exceptions at all? I can imagine they might want to specialize exceptions a little, if they really have provider-unique errors, but generally I'd expect a common set of exceptions would work for everyone. I'd like to see the exceptions tied more closely to the HTTP request/response that generated them. For instance, for exceptions to have a .request and .response attribute that would contain some object related to the request and response. And maybe a method like .debug_info() that would return a full report that could be submitted upstream. > * NodeSize should probably be renamed to NodeOptions. Size is a bit to > strict, if we start looking at things like the vCloud API -- which > allow you to choose CPUs and bandwidth. Size confused me a bit, but Options would be an even more confusing name to me. "Plan" is the word I think of when I think of size/bandwidth/etc packaged up with a price, but NodePlan isn't a very good name at all. That Size is a slight misnomer doesn't seem so bad, since at least it's fairly clear. Options could mean all sorts of things, e.g., some flavoring of an Image, or that you could select multiple Options and together they'd form a plan, or... well, it just seems like an overused word. > * Node/NodeImage/NodeOption should all have UUIDs that are globally > unique across the project. This is, for example, so you can get a list > of images across multiple providers and not have the id field collide. Would this mean some kind of mangling, like an id of "1234" would become "rackspace:1234", and then that would get split off again when sending the id over the wire? That would confuse me. Having a .uuid attribute on objects (which might be a property, generating the uuid from the id) would be less confusing. Also, sometimes I crosscheck information from libcloud against information found in a web interface or elsewhere, so a disconnect there might also be confusing. > * Docs! We do not really have any docs right now. It has proven to be > a pain to generate them because of the zope interfaces... What have you tried? I've been using Sphinx for everything of my own, but I don't know if it barfs on zope.interface stuff; Sphinx mostly requires explicitly listing what you want documented, so if you can just leave out the interfaces it seems like it should work. (I'm not sure what the interfaces really add anyway, but I guess that's a different discussion.) -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
