<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I have sent the mock of the Authorization and the asynchronous
    websocket task design only change the way front-end and back-end
    communicate. Changes are made between browser and the server.
    Actually user cannot feel the difference in operating in UI.<br>
    <br>
    Thanks &amp; Best Regards<br>
    <br>
    Wang Wen<br>
    <br>
    <div class="moz-cite-prefix">On 8/15/2014 1:44 AM, Aline Manera
      wrote:<br>
    </div>
    <blockquote cite="mid:53ECF57C.6050205@linux.vnet.ibm.com"
      type="cite">
      <div class="moz-text-html" lang="x-western">
        <meta http-equiv="content-type" content="text/html;
          charset=UTF-8">
        <tt>Hi all,<br>
          <br>
          As agreed in the last scrum meeting (<a moz-do-not-send="true"
            class="moz-txt-link-freetext"
href="http://kimchi-project.github.io/kimchi/meetings/kimchi.scrum.2014-08-13-13.02.html">http://kimchi-project.github.io/kimchi/meetings/kimchi.scrum.2014-08-13-13.02.html</a>),

          I am sending to you an overview about the sprint 2 tasks.<br>
          That way everyone can be aware of what is expected in each
          task and we don't block the UI development.<br>
          <br>
          Just to make clear, this is my view on each task!<br>
          Maybe you - the task owner - have a different view on that. In
          this case, share your ideas with us.<br>
          <br>
          And <b>don't forget to send a RFC, V1 patch, UI mockup </b>or

          something related to your task by <b>next Monday (08/18)</b><br>
          <br>
          This email is just a summary to motivate you! <span
            class="moz-smiley-s3"><span> ;-) </span></span></tt><br>
        <br>
        <font color="#3333ff" size="+1"><tt><b>ISO pool: Support to
              download ISO from URL (vianac)</b></tt></font><br>
        <tt>The idea here is to provide a way to user download a ISO
          from URL to the OOTB pool (ISO pool)<br>
          <br>
          POST /storagepools/ISO/storagevolumes/ {'name':
          &lt;vol-name&gt;, 'url': &lt;http|https|<a
            moz-do-not-send="true" class="moz-txt-link-freetext"
            href="ftp://url">ftp://url</a>&gt;}<br>
          <br>
          - name can be optional. We can generate one automatically
          based on ISO path when any name is provided by user.<br>
          - url is required.<br>
          <br>
          Questions:<br>
          - Which protocols will we support? http, https, ftp? Any
          other?<br>
          <br>
          - About the UI, how do we show this feature to user?<br>
            Basically we have 2 options:<br>
            1) In the storage tab:<br>
               Add an option "Add ISO" to the ISO pool (or any pool ?);
          get the URL and display a progress bar.<br>
            2) While creating a template:<br>
               Add an option "Download ISO"; get the URL and display a
          progress bar.<br>
               When the download is completed, we create a template
          using the new ISO.<br>
          <br>
            I prefer the first option (storage tab) as it can also be
          used for upload ISO (see below)<br>
        </tt><br>
        <font color="#3333ff" size="+1"><tt><b>ISO pool: Support to
              upload ISO</b></tt></font><br>
        <tt>This has a similar idea from downloading ISO from URL, but
          instead of providing a URL the user will select a local file
          on client side.<br>
          <br>
          POST /storagepools/ISO/storagevolumes/ {'name':
          &lt;vol-name&gt;, 'filepath': filepath}<br>
          <br>
          For the UI we also have the same 2 options from downloading
          ISO from URL feature<br>
          <br>
          I prefer the first one (storage tab) as we can use the same UI
          for both cases, download and upload.<br>
          <br>
          While selection "Add ISO" option, a new dialog will be
          displayed with a radio box: a browser input box (for upload)
          and a simple input box for URL (for download). The user can
          only select one option and confirm the operation.<br>
        </tt><font size="+1"><br>
          <tt><font color="#3333ff"><b>Create template from VM (rotru)</b></font></tt></font><br>
        <tt>This will use the same backing storage mechanism used to
          create a template from a IMG file.<br>
          <br>
          POST /templates {'name': &lt;template-name&gt;, 'vm':
          &lt;vm-name&gt;}<br>
          <br>
          About the UI:<br>
          We have 2 options:<br>
          1) When creating a template:<br>
             Add an option "From guest"; then list all guests to user
          choose one (or multiples ? ) and do the requests<br>
          2) On guests Actions menu<br>
             Add an option "Create template" and do the request<br>
             <br>
          I prefer the first option (while creating a template)<br>
        </tt><br>
        <font size="+1"><tt><font color="#3333ff"><b>Discover Kimchi
                peers(alinefm)</b></font></tt></font><br>
        <tt>This will use openSLP to register and discover Kimchi peers
          in the same network.<br>
          <br>
          GET /peers will return the Kimchi peers<br>
          [{server: <a moz-do-not-send="true"
            class="moz-txt-link-rfc2396E" href="https://1.2.3.4:8001">"https://1.2.3.4:8001"</a>},
          {server: <a moz-do-not-send="true"
            class="moz-txt-link-rfc2396E" href="https://1.2.3.5:8001">"https://1.2.3.5:8001"</a>}...]<br>
          <br>
          I think this feature should be optional, ie, we will have a
          config file entry that can be enabled/disabled - as this
          feature is not critical for virtualization and requires
          additional software installation (openSLP) and configuration.<br>
          <br>
          federation = enable|disable<br>
          <br>
          When enabled, the kimchi server will be register in the
          openSLP tool and when requesting /peers we will search for
          peers<br>
          <br>
          When disabled, /peers will return an empty list. Maybe it
          would be good to also display a message on UI "Federation
          feature is disabled for your Kimchi server."<br>
          To display that message, we need to update
          /config/capabilities to also return this info.<br>
          <br>
          GET /config/capabilities<br>
          { ...<br>
            federation: enable|disable<br>
          }<br>
        </tt><br>
        <font size="+1"><tt><font color="#3333ff"><b>Migration(Simon
                Jin)</b></font></tt></font><br>
        <tt>This task was added after we have finished the 1.3 Plan. So
          it would be difficult to accommodate the UI for it in out
          current plan.<br>
          So I'd say I only expect to have the backend done for 1.3
          release.<br>
          <br>
          POST /vms/&lt;name&gt;/migrate {server:
          &lt;other-kimchi-server-ip&gt;}<br>
        </tt><br>
        <font color="#3333ff" size="+1"><b><tt>Asynchronous event
              notify(Sheldon Feng/Zhengsheng Zhou)[backend]</tt></b></font><font
          size="+1"><br>
          <tt><font color="#3333ff"><b>Asynchronous event
                notify(WenWang)[UI]</b></font></tt></font><br>
        <tt>This is an important and big task. But I am not sure we will
          be able to finish it on time for 1.3 release.<br>
          We have already started some discussion on ML "[Kimchi-devel]
          [RFC] Improve task management for kimchi" (<a
            moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-June/006230.html">http://lists.ovirt.org/pipermail/kimchi-devel/2014-June/006230.html</a>)<br>
          <br>
        </tt><font color="#3366ff"><b><tt><font color="#3333ff"
                size="+1">Authorization: Allow admin user change
                permission settings when VM is running (WenWang)</font><br>
            </tt></b><tt><font color="#000000">The idea is display the
              same "Edit" dialog view when vm is running or not.<br>
              And when vm is running only enable the information that
              can be updated with running vm for editing.<br>
              That way we eliminate the "Manage Media" option and keep
              the UI consistent. And also provide a way to user checks
              the vm configuration (<a moz-do-not-send="true"
                class="moz-txt-link-freetext"
                href="https://github.com/kimchi-project/kimchi/issues/387">https://github.com/kimchi-project/kimchi/issues/387</a>)<br>
              <br>
            </font></tt></font><font color="#3333ff" size="+1"><tt><b>VM
              ticket: update novnc/spice code (sheldon)</b></tt></font><tt><br>
        </tt><tt>POST /vms/&lt;name&gt;/connect will automatically set a
          random console password for the VM and sets its expiration
          time to 10 seconds later.<br>
          When accessing the console URL, we need to pass the password
          as a parameter (password=...) so noVNC/Spice can do the
          connection to the guest console.</tt><tt><br>
        </tt><tt><br>
        </tt><tt><font color="#3333ff" size="+1"><b>Display iSCSI
              targets when iSCSI server is provided (backend done in
              3c6c5c) (Yu Xin)</b></font><br>
          It is similar to what we did for NFS servers. But in this case
          we will list the iSCSI targets for a given server.<br>
          <br>
          GET /storageservers?_target_type=iscsi<br>
          [<br>
            { "host":"127.0.0.1"<br>
              "port":"3260"<br>
            }<br>
          ]<br>
          <br>
          GET
/storageservers/&lt;server&gt;/storagetargets?_target_type=iscsi&amp;_server_port=&lt;port&gt;<br>
          [<br>
            {<br>
              "host":"127.0.0.1",<br>
             
          "target":"iqn.2003-01.org.linux-iscsi.localhost.x8664:sn.edb1a004dc57",<br>
              "target_type":"iscsi"<br>
            }<br>
          ]<br>
          <br>
          -----------<br>
          And thanks for your patience if you were reading this line
          now! <span class="moz-smiley-s1"><span> :-) </span></span><br>
          I know it is a big email but it could not be different based
          on the tasks we have for sprint 2.<br>
          <br>
          Feel free to use it as base for your RFC email.<br>
          I am looking forward to see all that done.<br>
          <br>
          Regards,<br>
          Aline Manera</tt><br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <div class="moz-text-plain" wrap="true" graphical-quote="true"
        style="font-family: -moz-fixed; font-size: 14px;"
        lang="x-western">
        <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
      </div>
    </blockquote>
    <br>
  </body>
</html>