incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Bicking <>
Subject Re: [libcloud] We need a release (libcloud in Debian and Ubuntu apt repos)
Date Thu, 10 Dec 2009 21:04:37 GMT
On Thu, Dec 10, 2009 at 1:51 PM, Tom Davis <> wrote:
>> I'd like to see better debugging support.
> Could you elaborate on that?

When anything goes wrong, I want to see exactly what was sent and what
was received (including headers).  Sometimes even when things go
right; for instance, I learned Rackspace returns 203 Non-Authoritative
Information when you get cached responses.  Had I seen that somehow, I
would have known not to trust those responses.  (That it gives
nonauthoritative information is itself kind of stupid, and is
something they need to be pushed on, but for now it's out there.)

For successful responses, I'm not really sure.  Maybe the logging
module?  For errors, there's an exception object that can have
everything attached to it, though it may not know the entire history
of requests and responses, only the last request/response that led to
the error.  Still, that would be useful.

Something like .parse_error is a bit suspicious to me, as it can throw
away information.  In the current code the RackspaceResponse object
throws away the actual error message.  I submitted a pull request with
a fix... but that just saves the text, which is nice because it is
readable, but I want the XML to be saved too.  When something goes
wrong you can't really trust anything.

> 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.
> I'll stop the quote there to make this point: you don't need *the* node, you
> just need something that *conforms to the interface of a node*. Implementing
> *INode* gives you this, but in your example all you need is some object with
> some attribute "id". If you want to store the IDs to save on network i/o
> then by all means, store those IDs and stick them as an *id* attribute on
> some object.

That's true.  I wish I could serialize objects to a string and parse
them from a string, without having to inspect the code to see what the
essential piece is.  Like you say, it's .id for some services, and
.id+.slug for another, etc.

I gettable/settable full_id or something like it would be nice; it
might be derived from multiple pieces.  E.g., for RimuHosting, maybe
you'd do:

def _get_full_id(self):
    return + ':' + self.slug
def _set_full_id(self, value):, self.slug = value.split(':', 1)
full_id = property(_get_full_id, _set_full_id)

I just really like strings because you can put them in nice text
configuration files.

> ID's aren't accepted because it isn't safe to assume the only necessary
> information will be an ID (e.g. RimuHosting uses a "slug" attribute). You
> can look at the code to find out what your provider(s) need and optimize
> your own usage that way. You can also feel free to instantiate your own
> NodeImage and Node objects as found in; they're little more than
> dictionaries with some convenience methods.
> I feel it would be more confusing to provide additional ways to
> create/destroy nodes than it is for industrious developers to sidestep the
> issue by making their own barebones conforming objects.


> My own stuff:
>   - What about the interfaces interferes with proper documentation?
>   - Glancing through the code just now I've noticed a lot of clobbering of
>   reserved words (the global "id", "object", etc.) This sort of stuff should
>   have been cleaned up before it got into master...

I think .object doesn't really mean anything, so it's not a very good
use of a reserved word, but the id attribute is sensible, and doesn't
really clobber anything.  Plus the id() builtin isn't particularly

Ian Bicking  |  |

View raw message