On 18 Jun 2012, at 11:25, Dave Scott wrote:
> Anil wrote:
>> This is an odd one to have in the storage-specific API. Is it
>> exactly the same Task API as the rest of the XenAPI, and
>> duplicated because of the rpc-light interface?
>>
>> From a client perspective, it would be good to use exactl
Hi Anil,
On 15 Jun 2012, at 16:31, Dave Scott wrote:
> task_tracking: allows long-running operations to be tracked
> Task.cancel: cancel a long-running operation
> Task.destroy: forget about a finished task
> Task.list: list currently-known tasks
> Task.stat: query the state of a particular t
Hi Anil,
> Can you version the URL endpoints at the same time? e.g.
> HTTP POST /v1/core
Good idea!
> I didn't spot this laid out, but how does this relate to the storage
> manager plugins? Does this maintain backwards compatibility with that
> layer, or are they rewritten too?
In the current c
On 15 Jun 2012, at 16:31, Dave Scott wrote:
> task_tracking: allows long-running operations to be tracked
> Task.cancel: cancel a long-running operation
> Task.destroy: forget about a finished task
> Task.list: list currently-known tasks
> Task.stat: query the state of a particular task
> Upd
On Fri, Jun 15, 2012 at 04:31:06PM +0100, Dave Scott wrote:
> Over the last few months the storage interface has become a lot bigger,
> with support for disk mirroring, cross-SR disk copies, task cancellation
> and event notification.
>
> It's become clear that the interface isn't very well-factor
Over the last few months the storage interface has become a lot bigger,
with support for disk mirroring, cross-SR disk copies, task cancellation
and event notification.
It's become clear that the interface isn't very well-factored. Clearly
a driver domain will only want to implement some basic sub
