deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <>
Subject Re: making cimi tests pass on fgcp
Date Mon, 04 Feb 2013 22:34:43 GMT
On Mon, 2013-02-04 at 16:15 +1100, Koper, Dies wrote:
> To get the tests to pass on the fgcp I have to work around the same
> restriction with the fgcp endpoint API that affected the api tests: when
> you create a resource (machine/volume) or delete one, it does not accept
> any other resource creation/deletion requests in that system until the
> creation/deletion has completed.

I think you have the analysis of the issue spot-on: the issue is that
the FGCP API does not support the kind of usage that CIMI mandates, and
that the two other frontends at least implicitly expect.

That means that no amount of fixing up of tests will actually address
breakage that will be built into our frontends when using the FGCP

Rather than working around this in the tests, we need to take a good
look at what it takes to beef up the FGCP driver so that DC users will
get the behavior they expect. I know that that will require some heavy
lifting, including making the DC server stateful (at least with the FGCP
driver) and adding a task queue/daemon, but I'd rather do that than
force every user of DC to special-case FGCP and be prepared for
driver-specific behavior.

There's actually a good case to be made to add task queue capabilities
to Deltacloud for other things, too, and we might get somebody else to
work on that. For FGCP, what I am not clear on is the extent of what
needs to be buffered/sequenced for the API. For example, I'd imagine
that FGCP instance launching goes into this task queue, and requests get
buffered there, so that the global locking of FGCP is invisible to the

Dies, could you write up something that outlines what sort of requests
need to be buffered and made dependent on each other ?


View raw message