DreamHost does a similar thing where the server isn't actually created right away. I ended up rewriting how we provision our servers so that we now reserve an ID before the server is actually created and can return that to create_node. You might try something like that.
~Kyle Marsh On Tue, May 25, 2010 at 12:14, Paul Querna <[email protected]> wrote: > On Tue, May 25, 2010 at 12:10 PM, Roman Bogorodskiy > <[email protected]> wrote: >> Alex 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 minutes >> 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? >
