[Top Posting] Let's try to concentrate on the subject of this thread (we can discuss shared disks in a separate thread):
- I agree with Ori: Disks root collection should have all disks, not only floating (shared?) disks. Disk is an important business entity, which "deserves" a full root collection of its own - I think it is more aligned with the existing api structure (VMs are shown both in the VMs root collection as well as under their Cluster/DC). - Regarding possibilities 1 vs. 2 below: I prefer #1 (again - agreeing with Ori, IIRC): Although risky in a sense, at least existing users/scripts won't be harmed because of this, since the behavior is backward compatible. Regarding new users - they should know what they are doing, and they should always be careful when using DELETE, no matter from which context. It also "looks" better (more symmetrical, adding a new POST action is avoided). Comments? ----- Original Message ----- > From: "Ori Liel" <ol...@redhat.com> > To: engine-devel@ovirt.org > Cc: "Eoghan Glynn" <egl...@redhat.com> > Sent: Monday, April 16, 2012 3:33:27 PM > Subject: Re: [Engine-devel] Floating Disks implementation in REST-API > > 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). > > 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. > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel