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 driver. 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 user. Dies, could you write up something that outlines what sort of requests need to be buffered and made dependent on each other ? David
