Mailing-List: contact libcloud-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: libcloud@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of paul@querna.org designates
 209.85.221.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20100525191024.GC2744@fsol>
References: <20100507094623.GC2025@rbogorodskiy>
	 <DC4FA98C-BF80-40DA-B416-077C5C6452EE@apache.org>
	 <20100525183216.GB2744@fsol>
	 <AANLkTikAcru1NDg_q3FWs82KO0Hy7K-K9gyHOa99uh6y@mail.gmail.com>
	 <20100525191024.GC2744@fsol>
Date: Tue, 25 May 2010 12:14:54 -0700
Message-ID: <AANLkTil0FzCu8blML0Pdv_p9_YiR3LR9YF8A9i2FysnE@mail.gmail.com>
From: Paul Querna <paul@querna.org>
To: libcloud@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [libcloud] GoGrid driver regression?

On Tue, May 25, 2010 at 12:10 PM, Roman Bogorodskiy
<bogorodskiy@gmail.com> wrote:
> =C2=A0Alex Polvi wrote:
>
>> Roman,
>>
>> The problem is that the driver must return with an ID. Perhaps we need
>> to block and run list_nodes until the node has an id? Lame, but it
>> makes the interface consistent.
>
> I don't quite like idea with blocking. It takes quite a lot of time to
> get id assigned. Here's a typical session of creating a new server on
> GoGrid:
>
...
>
> This output was generated by gg-tools (http://novel.evilcoder.org/gg/)
> that I wrote back then. First column is id, empty column means that id
> wasn't assigned yet.
>
> Please note the timestamps in the shell prompt -- it takes about 3 minute=
s
> to get id assigned! Imagine if somebody's creating a node in some web's
> framework view and expects to return quickly. If the method will block
> for 3 or so minutes it won't be any good, IMO.

Eeek.  I think we will need to block.  We do this in the softlayer
driver too, it is definitely less than ideal -- but the consistent API
we are trying to provide right now makes the promise that the node id
(and uuid) returned from create_node is the same as what will be
returned from a future list_nodes -- othwerise its even more difficult
for code built on top of libcloud to coorelate these IDs in a cross
provider way, so this is why I think it will need to block until it
can get the right ID for the UUID.

> Maybe we could just return -1 or some other special value for a just
> created server?