[Kimchi-devel] [RFC] UI - Live migration UI design

Mon Nov 16 16:06:13 UTC 2015

Hi,

Regarding the UI we currently have these two widgets:
-wok.confirm that displays a title, a message and an "Ok" and "Cancel" buttons;
-wok.window that displays a modal window and we have full control of the HTML inside of it.

Does this feature really requires that we create a new JS widget? I think we can use wok.window and bootstrap default modal elements and then wok.confirm to trigger the "Disclaimer" message, like the attached screenshot. 
I thought that since this process could take a long time to finish, we should have a progress bar or something but I think a better place to display this should be Guests page instead of the modal window unless we have some sort of "block-UI" while the migration is still in progress.

If we do have to create a new widget, then I think we can use a Wizard. I'm attaching 4 samples of it.

Regards,
Samuel

-----Original Message-----
From: kimchi-devel-bounces at ovirt.org [mailto:kimchi-devel-bounces at ovirt.org] On Behalf Of Daniel Henrique Barboza
Sent: segunda-feira, 16 de novembro de 2015 10:43
To: kimchi-devel at ovirt.org
Subject: Re: [Kimchi-devel] [RFC] UI - Live migration UI design

On 11/13/2015 12:23 PM, Walter Niklaus wrote:
>
>
> On 13.11.2015 14:09, Daniel Henrique Barboza wrote:
>> Hi,
>>
>> The backend for this feature is almost completed and the API is 
>> defined, so let's talk about the UI.
>>
>> This is the API (note: the upstream version is outdated, will be 
>> updated in an incoming patch):
>>
>> **URI:** /plugins/kimchi/vms/*:name*
>>
>> * **POST**: *See Virtual Machine Actions*
>>
>> **Actions (POST):**
>>
>> * migrate: Migrate a virtual machine to a remote server, only support 
>> live mode without block migration.
>>     * remote_host: IP address or hostname of the remote server.
>>     * user *(optional)*: User to log on at the remote server.
>>     * password *(optional)*: password of the user in the remote 
>> server
>>
>>
>> This API will return a task ID for the UI to track its progress, 
>> pretty much like it is done with the 'clone' feature.
>>
>> This is how I imagine the UI:
>>
>> - a button called "migrate" at the same submenu as clone VM.
>>
>> - when pressed, a new window appears with the following content:
>>
>> --------
>> "Disclaimer: this process cannot be stopped after started, can take a 
>> long time to complete and will turn off this current VM when it is 
>> over."
> I would propose to change the wording: will turn off this current VM 
> when it is over.   into something like:    will turn off the VM on 
> this Hypervisor when it is sucessfully migrated to the remote 
> destination.
Fine by me!

> Sorry, but I don't remember if we allow static migration as well ? If 
> we do, then we may have to display a different text for the static 
> migration.

The static migration (non shared storage migration) are waiting review in the ML. It'll be upstream soon.

The post-migration behavior is the same from the shared storage migration, so I don't believe we'll need two different texts in this scenario.
>
>>
>> * textfield to input the remote_server, name "remote server"
>>
>> * checkbox with text: "Delete this VM when the migration is completed"
>>
> Typically the VM definition, and I guess this is what the checkbox is 
> reffering to, is migrated to the remote host as well in order to allow 
> full management of this VM on the remote host (like changing its 
> configuration). I'm aware that we are not doing such actions in this 
> first release.
Actually we are. If the VM is persistent (= has a configuration file inside libvirt) it will have a configuration file in the destination host and it will, or it should be, fully manageable on the remote host as if it was a VM created there.

> However migrating the VM definition has a sideeffect we may want to 
> consider in this scope:  it makes sure that you can not have multiple 
> instances of the VM running on different hosts. This aspect is 
> releveant only if starting the VM multiple times is causing a conflict 
> on a resource like: the same SCSI disk as boot device.
> I'm wondering that if the user doesn't select the above checkbox we 
> should put out a warning like:  "Restarting the VM locally may cause 
> resource conflicts with the migrated instance"
Hmmmm that's a fair point. I believe we can add this warning text as well.

>>
>> Text: "The following fields are optional. Fill them if you want 
>> Kimchi to setup a password-less ssh session between the localhost and 
>> the remote host. The setup process will only be successful if the 
>> user has 'SUDO ALL' permission in the remote machine"
>>
>> * textfield to input the username of the remote host
>> * password field to input the password of the user in the remote host
>>
>> * "Cancel" and "Start" buttons at the bottom
>>
>> -------------
>>
>>
>> This is the workflow/behavior I would expect of it:
>>
>> - clicking "Cancel" at any time will dismiss the window and nothing 
>> happens;
>>
>> - clicking "Start" without remote_host field will issue an error 
>> "remote host field cannot be blank" or something like that
>>
>> - clicking "Start" with a remote host field will start the process
>>
>> - clicking "Start" with remote host and only one of the user or 
>> password filled will raise an error "both user and password fields 
>> must be filled".
>>
>> - if, **and only if **,  the user checks the checkbox "Delete VM 
>> ....", the UI will delete the VM after the migration process is 
>> completed by using the proper API (I believe it is DELETE /vms/name).
>>
>>
>> This is all I have for the UI for this feature ATM. I'll update this 
>> RFC if required.
>>
>>
>> Please provide comments and suggestions. The final backend for this 
>> feature will be submitted to the ML at the start of the next week.
>>
>>
>> Let me know if there's any doubts about how Kimchi's live migration 
>> backend
>> works.
>>
>>
>>
>> Daniel
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel

_______________________________________________
Kimchi-devel mailing list
Kimchi-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wizard-4.png
Type: image/png
Size: 121442 bytes
Desc: wizard-4.png
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151116/81c1f941/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wok.confirm.png
Type: image/png
Size: 29356 bytes
Desc: wok.confirm.png
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151116/81c1f941/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wizard-1.jpg
Type: image/jpeg
Size: 21299 bytes
Desc: wizard-1.jpg
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151116/81c1f941/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wizard-2.png
Type: image/png
Size: 27291 bytes
Desc: wizard-2.png
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151116/81c1f941/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wizard-3.png
Type: image/png
Size: 63977 bytes
Desc: wizard-3.png
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151116/81c1f941/attachment-0003.png>