>
>
>On 04/16/2012 02:33 PM, Ori Liel wrote:
>> I'd like us to move forward with this.
>>
>> The option of using 'attach' action does not exist, because, as Eoghan 
>> observed, we would be executing an action on an entity which doesn't exist 
>> in the collection: (.../api/vms/{vm:id}/disks/???-no entity-???/attach)
>>
>> There are two options left on the table; let's see if we can agree on one of 
>> them:
>>
>> 1)
>>          POST/api/vms/{vm:id}/disks
>>          <disk id="{disk:id}"/>                                =>   attach 
>> disk
>>
>>          DELETE .../api/vms/{vm:id}/disks/{disk:id}
>>          <disk><detach>true</detach><disk>                     =>   detach 
>> disk
>>
>> Pros: symmetrical
>> Cons: risky (if user wants to detach but forgot to give parameter, disk will 
>> be deleted).
>
>My idea for that was to introduce <force>true|false</force> as well.
>Without force=true, we won't delete a disk if it's currently floating.
>

If the disk is floating it will only appear in root collection (...api/disks), 
and DELETE from 
there is non-ambiguous, as there's no option to detach - so I don't see how 
adding 'force' there 
helps us. 

In your previous mail you suggested the same thing for attached floating disk, 
so perhaps you meant
that here as well? (sorry for only responding now, by the way). But that does 
break API - for example, 
a simple script deleting all disks from a VM would fail because suddenly 
deleting requires 'force=true'. 


>I think it makes it less risky. And it is still backwards compatible, as
>3.0 clients do not know how to create a floating disk, and therefore
>there is no risk that they are deleting one.
>
>Regards,
>Geert
>
>
>>
>> 2)
>>
>>          POST/api/vms/{vm:id}/disks
>>          <disk id="{disk:id}"/>                                =>   attach 
>> disk
>>
>>          DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach    =>   detach 
>> disk
>>
>> Pros: not dangerous
>> Cons: asymmetrical, attach done like add, but detach done using action.
>>
>>
>> No solution is perfect but we need to decide.
>>
>> Thanks,
>>
>> Ori.
>
>-- 
>Geert Jansen
>Sr. Product Marketing Manager, Red Hat Enterprise Virtualization
>
>Red Hat S.r.L.           O: +39 095 916287
>Via G. Fara 26           C: +39 348 1980079 (when in US: 415-623-0542)
>Milan 20124, Italy       E: gjan...@redhat.com
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Reply via email to