<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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.<br>
    <br>
    Thanks<br>
    -Socorro<br>
    <br>
    <div class="moz-cite-prefix">On 11/16/2015 08:06 AM, Samuel Henrique
      De Oliveira Guimaraes wrote:<br>
    </div>
    <blockquote
      cite="mid:e946b7941eb341c68ca072643dc90814@serv030.corp.eldorado.org.br"
      type="cite">
      <pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:kimchi-devel-bounces@ovirt.org">kimchi-devel-bounces@ovirt.org</a> [<a class="moz-txt-link-freetext" href="mailto:kimchi-devel-bounces@ovirt.org">mailto:kimchi-devel-bounces@ovirt.org</a>] On Behalf Of Daniel Henrique Barboza
Sent: segunda-feira, 16 de novembro de 2015 10:43
To: <a class="moz-txt-link-abbreviated" href="mailto:kimchi-devel@ovirt.org">kimchi-devel@ovirt.org</a>
Subject: Re: [Kimchi-devel] [RFC] UI - Live migration UI design



On 11/13/2015 12:23 PM, Walter Niklaus wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">

On 13.11.2015 14:09, Daniel Henrique Barboza wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">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."
</pre>
        </blockquote>
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">Fine by me!

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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.
</pre>
      <blockquote type="cite">
        <pre wrap="">
</pre>
        <blockquote type="cite">
          <pre wrap="">
* textfield to input the remote_server, name "remote server"

* checkbox with text: "Delete this VM when the migration is completed"

</pre>
        </blockquote>
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">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.


</pre>
      <blockquote type="cite">
        <pre wrap="">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"
</pre>
      </blockquote>
      <pre wrap="">Hmmmm that's a fair point. I believe we can add this warning text as well.


</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>

</pre>
        </blockquote>
        <pre wrap="">
_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
      </blockquote>
      <pre wrap="">
_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>