[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] the xapi storage interface

  • To: 'Anil Madhavapeddy' <anil@xxxxxxxxxx>
  • From: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
  • Date: Mon, 18 Jun 2012 11:25:56 +0100
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: "xen-api@xxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 18 Jun 2012 10:26:04 +0000
  • List-id: User and development list for XCP and XAPI <xen-api.lists.xen.org>
  • Thread-index: Ac1NO3JZU8qmb7wNRCa/fg9OW9GDGwAANKIA
  • Thread-topic: [Xen-API] the xapi storage interface

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 task
>  Updates.get: block waiting for updates, with timeout

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 exactly the
> same task/event/wakeup API for all operations, not just storage.

Yup, it's basically the same interface. I agree it would be better to share it 
somehow -- I'll see if I can keep it separate and stop storage-specific types 
from accreting into it. At the moment it's a bit polluted with "SR" and "VDI" 
types but I could make it more dynamic and then wrap a type-safe layer onto it 
for the storage implementation in particular.


Xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.