I can imagine this kind of issue could occur for more providers and more cases. As for the fgcp, in many of the methods I get a list first of resource ids and then make subsequent calls for each to retrieve all the details I need. Although deleting with fgcp is an instant operation so it's not likely for a GET after a DELETE to fail because the resource lingered for a bit, another client could delete a resource while a client is retrieving a listing so especially with many resources (i.e. many calls to the backend for a few seconds) the chance of failure is there. The fix should be easy, a rescue block in the right place skipping the resource if an error occurs because it disappeared.
I'll look at this for the fgcp next week. Can others look at it for the drivers they have test accounts for? Regards, Dies Koper > -----Original Message----- > From: David Lutterkort [mailto:lut...@redhat.com] > Sent: Saturday, 16 February 2013 11:14 AM > To: dev@deltacloud.apache.org > Subject: Re: [PATCH] DTACLOUD-462 - a GET for an instance can fail while > a different instance is being destroyed. > > On Fri, 2013-02-15 at 14:51 -0800, David Lutterkort wrote: > > What happens when somebody requests /api/instances while an instance > is > > being destroyed ? The fix you have for the single-instance case is spot > > on, but we must also guard against tripping over this when listing all > > instances. > > And DTACLOUD-484 already captures this ... > > David > >
