Re: [Engine-devel] restapi - removing template from a specified storage-domain
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Omer Frenkel" <ofrenkel(a)redhat.com>
Cc: "Ori Liel" <oliel(a)redhat.com>, engine-devel(a)ovirt.org, "Geert
Jansen" <gjansen(a)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(a)redhat.com>
>> To: engine-devel(a)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.