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

Mon Nov 16 16:19:47 UTC 2015

I think a simple panel is all we would need for this UI at this time, 
just a little bit more elaborate than the clone UI in that it requires a 
few more fields.  Just trying to figure out which is the best approach.

Thanks
-Socorro

On 11/16/2015 08:06 AM, Samuel Henrique De Oliveira Guimaraes wrote:
> 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
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20151116/e776aaa9/attachment.html>