Hi David, > 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
Actually, I expect this issue (the system blocking) will be picked up as Fujitsu develops its own cimi API and will be addressed in the not too distant future. So I prefer to apply Band-Aids for a little while longer, so we can at least keep testing the cimi front-end with fgcp easily as its coverage increases. I'd rather look at your solution as a plan B in case the problem will not be solved on the fgcp api side and more cimi clients appear. > 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 Yes, I did give it some thinking last month and it's basically a job engine we'd have to develop. So plan B may be to piggy back on the cimi jobs implementation. There is of course the issue that no clients (including DC tests) are written to work with that but at least it'd be cimi compliant :-p > Dies, could you write up something that outlines what sort of requests > need to be buffered and made dependent on each other ? The scope is the system. Currently all resources are created into a system, they can't be created outside a system. - machine creation - machine deletion - volume creation - volume deletion - acquiring a public IP address - returning a public IP address What a queuing system could do, is first try the operation regardless (as even if the queue is full, fgcp endpoint will do parameter validation) so that in case of invalid parameters or invalid state (e.g. trying to delete a machine that is not in the stopped state) the client can be notified directly. If the endpoint returns an error that the system is locked, add it to the queue. The queue periodically retries the operations. With machine and volume create operations, we need to return an id. We could use the system id + machine name, so at least the machine could be programmatically identified later (unless the client creates machines with the same name). With the public IP address... I suppose a (stateful) job mechanism is the only way? Regards, Dies Koper > -----Original Message----- > From: David Lutterkort [mailto:[email protected]] > Sent: Tuesday, 5 February 2013 9:35 AM > To: [email protected] > Subject: Re: making cimi tests pass on fgcp > > 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 > >
