----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Omer Frenkel" <ofrenkel@redhat.com> Cc: "Ori Liel" <oliel@redhat.com>, engine-devel@ovirt.org, "Geert Jansen" <gjansen@redhat.com> Sent: Sunday, January 1, 2012 9:44:47 PM Subject: Re: [Engine-devel] restapi - removing template from a specified storage-domain
On 01/01/2012 05:59 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Ori Liel"<oliel@redhat.com> To: engine-devel@ovirt.org Sent: Sunday, January 1, 2012 3:15:18 PM Subject: [Engine-devel] restapi - removing template from a specified storage-domain
I'm about to implement removing template from a specified storage-domain.
A template is meta-data + disks. The meta-data is in the ovirt-engine database, the disks are (potentially) scattered across several storage-domains. Removing a template from a specified storage domain means removing that template's disks from that storage-domain. API-wise, it's better to enable the deletion at the single-disk level, otherwise rollback and all sorts of unnecessary complexities enter the picture. So what I would like to go forward with is the following API:
DELETE /api/templates/{template_xxx}/disks/{disk_yyy}
<storage_domain id="domain_zzz"/>
This means: "delete the disk 'disk_yyy' (which belongs to template 'template_xxx' from the storage-domain 'domain_zzz'.
Any comments?
just that CURRENT backend only allows removing per storage domain(s), this functionallity is in plan, though (if that was what you meant..)
I think the implementation for this can/should wait for the new support in the backend if makes more sense api-wise, rather than implementing based on the current limitations and later changing the api. the question is with the move to multiple storage domains, will an atomic[1] verb to delete all disks from a specific storage domain (per vm/template) will be provided, or only per disk.
[1] well, delete is rollforward, so not sure i understand Ori's point about rollback. OTOH, the API should probably behave the same for move/copy of disks, etc.
What I meant by rollback issues is: how do we handle a scenario in which deletion of disk1 succeeds, but then deletion of disk2 fails? When you say 'delete is rollforward', I assume you mean that delete operations don't require roll-back, and that even if only partial deletion was done - that's ok (I'm verifying because I'm not familiar with the term roll-forward). Assuming this is what you meant, I still prefer the per-disk deletion, because the scenario of partial success still requires extra handling: 1) Backend would have to generate a complex message that disk1 was deleted but disk2 not. 2) REST-API user might resend the same request to retry - and fail because this time disk1 does not exist.