[Engine-devel] restapi: New params for import VM/Template

[Simon Grinberg]

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Simon Grinberg" <sgrinber at redhat.com>
> Cc: "Michael Pasternak" <mpastern at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Itamar Heim"
> <iheim at redhat.com>, "Livnat Peer" <lpeer at redhat.com>, "Ori Liel" <oliel at redhat.com>
> Sent: Thursday, May 17, 2012 10:21:51 AM
> Subject: Re: [Engine-devel] restapi: New params for import VM/Template
> 
> cc'ing Simon,
> 
> Hi Simon,
> 
> I remember we talked about why the engine can't decide implicitly if
> to clone the vm or not - it should be the user call?
> Can you share your opinion about that?

Sorry for missing on that. 

First reason informative - User should know what he and we are doing. 
Example:  * Setup2 already has vm named Kuku imported few months back or by another admin
          * The admin that usually works on setup1, decides it's time to move the VM to setup2 (for any reason), so he exports kuku and then imports into setup1 
          * We automatically import as Kuku1
          * Admin searches for the name kuku and starts it - he is now working on the old one without knowing it. 
The above can cause confusion, lost time to understand why kuku is not working as expected and/or lost time to fix the err when trying to merge data from the currently running kuku and kuku1 which is the VM the user actually wanted to use.  

We must stop and ask. 
The question should be very similar to file copy on decent OSs - Override, save as, cancel. So does the API for this operation.

* The above also leads to also question if importing a VM with the same name as a vm in the system, even though it is clear it's a different VM (different GUID/image ID etc)

Second reason - prevent user error:
User writes a script, by mistake he tries to copy the same VM over and over (he meant other VMs or just wrong stop condition), he can easily fill out his storage domain, or waste a lot of time before discovering the mistake since we don't return error but silently clone as new,

Again the options above should be suffice to prevent that, if the user decides to to use with the force overrider or always clone, that is his problem. 

Third one, convenience:
Assume a user has a VM on setup1, and wants a similar but not identical setup2. The reason is that he may want some day to move the VM to setup2. There is no support at all for this scenario. 
it will be either, the VM is imported as is and if he wants to move over the original VM it will have to be cloned (Thus changed). Or he can import and clone now (redundant copy operation)  - The use case here is similar for the clone VM functionality but the clone is into a different setup. We should not always assume that it's fine to have identical VMs on different setups.

I can think of some more if it's really necessary :

 
Bottom line: Having this now will save at least 3 RFEs coming from the reasoning above and in a very reasonable price. All we have to do is to allow a checkbox in the import menu and stop assuming that we know better then the user what he wants to do. 
If you have a functionality that on one hand makes a novice user life easier while on the other hand may restrict advanced users, allow to choose - just have the defaults set to the case you think is the most common.

The said above assumes clone on import changes everything including image IDs otherwise all the said above is a moot point.


* Now in more advanced scenarios, use may be able to change everything he's allowed to change - same as when he does "Clone VM from template". But this is extension to simple clone case, with the price of going to the VM properties and edit it is solvable.

* If override is complex for now, then reject if not specifically stated to clone (in the API) and Question to Copy As or Cancel is also reasonable. The user can always choose cancel and delete before trying again.   




> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "Michael Pasternak" <mpastern at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>, "Itamar Heim"
> > <iheim at redhat.com>
> > Sent: Thursday, May 17, 2012 9:43:45 AM
> > Subject: Re: [Engine-devel] restapi: New params for import
> > VM/Template
> > 
> > 
> > > 
> > > Going FW it would be nice to override parameters in import
> > > vm/template
> > 
> > 
> > I agree with you and that's why -
> > 
> > As a user I don't think there should be a difference in the API
> > between:
> > - Importing a VM and changing it's name
> > - Importing a VM for the second time
> > 
> > The reason you want to add artificial difference between the two
> > scenarios above is because currently there are implementations
> > limitations (changing the image ID while importing is not supported
> > yet)
> > 
> > I think that we should solve the limitations in the implementation
> > instead of making our API cumbersome (implicit clone by name and
> > adding
> > some clone entity are both bad IMO).
> > 
> > 
> > 
> > Livnat
> > 
> > 
>