incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <p...@querna.org>
Subject Re: [libcloud] Re: svn commit: r938156 - in /incubator/libcloud/trunk: libcloud/ libcloud/drivers/ test/ test/fixtures/ecp/
Date Wed, 28 Apr 2010 00:02:47 GMT
On Tue, Apr 27, 2010 at 12:15 PM, Viktor Stanchev <viktor@enomaly.com> wrote:
> Paul,
> I made all the changes to the ECP driver that were suggested. They are in
> the attached patch. I tested it live and everything appears to work
> including InvalidCredsException, common errors and all features. I moved
> error checking to the universal error checking function rather than having
> it for each request.
> I have a few questions though.
> - When creating a VM, should the driver wait for a VM to be finished
> creating before returning?
> If so, then I'd have to modify the driver slightly. If not, it seems that
> there is no way to check if the creation is still in progress or if it
> failed eventually. Maybe you should look into adding a feature to check the
> status of transactions?

As long as the Node.id returned from create_node is correct, so a
future call to list_nodes will return a node with the same ID, we
consider this 'good enough'.  If you need to block in create_node
until some object is created on the backend, you can see how the
Softlayer driver does this because we can't get the node ID right
away. It isn't ideal, but we are trying to enforce that while
create_node might return a Node object in a state of pre-booting, the
ID attribute is accurate.

> - The ECP API has no way to "restart" a VM, instead, I'm turning it off and
> then back on. This takes a bit longer than normal, but is inevitable. I
> guess I can make the reboot happen in a separate thread, but it doesn't seem
> that useful and the error checking won't be reliable. Should I try that?

I would avoid spinning up a thread, and instead just block.  We are
trying to provide an abstraction layer, and sometimes that might be a
little slower, but it would be best to be able to still catch errors
in a consistent manner.


> - The ECP software is used by multiple service providers. We only create the
> software. Therefore there are multiple URLs that it would connect to. How do
> you plan to address this issue? I think adding a wrapper class that sets a
> different URL as the "host" would be the best solution, but it's also
> possible to allow the user of libcloud to select an arbitrary URL.

The node constructor should take an URL.  We are dealing with this
right now in the Eucalyptus and OpenNebula drivers too.  I think we
will end up with a custom subclass of some kind, CustomURLConnection
or some-such in the long run, but for now I'd suggest just copying
what the Eucalyptus driver does in trunk.

> - The node states are not used very well right now, but I don't know if
> there's anything I can do about it. The node states in ECP don't match the
> node states in libcloud.

What states does ECP expose for a node?

Thanks,

Paul

Mime
View raw message