<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 08/18/2014 03:55 AM, Royce Lv wrote:<br>
    </div>
    <blockquote cite="mid:53F1A35C.2090908@linux.vnet.ibm.com"
      type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 2014&#24180;08&#26376;15&#26085; 01:44, Aline Manera
        wrote:<br>
      </div>
      <blockquote cite="mid:53ECF57C.6050205@linux.vnet.ibm.com"
        type="cite">
        <meta http-equiv="content-type" content="text/html;
          charset=ISO-8859-1">
        <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>
        </tt></blockquote>
      <tt>I prefer using an action rather than POST to collection
        itself, reasons:<br>
      </tt><br>
      <tt>&nbsp;&nbsp;&nbsp; 1. If upload share the same REST API with create volume,
        the model logic of create volume will be messed up. Since upload
        and create fulfill different tasks, we have reason to
        distinguish them.<br>
        &nbsp;&nbsp;&nbsp; 2. If in the future, we support create volume based on
        another storage volume, we may use identical parameters and API
        as this one. That will confuse user.<br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; So to make the REST API match its function, I prefer to
        use "POST upload".<br>
        <br>
        I think upload and download can share same REST API.<br>
      </tt>
      <blockquote cite="mid:53ECF57C.6050205@linux.vnet.ibm.com"
        type="cite"><tt> <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>
        </tt></blockquote>
      <tt>As I have proposed to utilize libcurl, I think we can keep in
        line with protocols libcurl support.<br>
        Also qemu iso streaming uses libcurl, so if a user found an ISO
        useful when using iso streaming, he may want to download it with
        kimchi.<br>
        If we keep same protocol, same urls can be used.<br>
      </tt></blockquote>
    <br>
    ACK.<br>
    <br>
    <blockquote cite="mid:53F1A35C.2090908@linux.vnet.ibm.com"
      type="cite"><tt> </tt>
      <blockquote cite="mid:53ECF57C.6050205@linux.vnet.ibm.com"
        type="cite"><tt> <br>
          - About the UI, how do we show this feature to user?<br>
          &nbsp; Basically we have 2 options:<br>
          &nbsp; 1) In the storage tab:<br>
          &nbsp;&nbsp;&nbsp;&nbsp; Add an option "Add ISO" to the ISO pool (or any pool ?);
          get the URL and display a progress bar.<br>
          &nbsp; 2) While creating a template:<br>
          &nbsp;&nbsp;&nbsp;&nbsp; Add an option "Download ISO"; get the URL and display a
          progress bar.<br>
          &nbsp;&nbsp;&nbsp;&nbsp; When the download is completed, we create a template
          using the new ISO.<br>
          <br>
          &nbsp; I prefer the first option (storage tab) as it can also be
          used for upload ISO (see below)<br>
        </tt></blockquote>
      <tt>ACK.</tt><br>
      <blockquote cite="mid:53ECF57C.6050205@linux.vnet.ibm.com"
        type="cite"><tt> </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>
          &nbsp;&nbsp; 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>
          &nbsp;&nbsp; Add an option "Create template" and do the request<br>
          &nbsp;&nbsp; <br>
          I prefer the first option (while creating a template)<br>
        </tt></blockquote>
      <tt>ACK.</tt><br>
      <blockquote cite="mid:53ECF57C.6050205@linux.vnet.ibm.com"
        type="cite"><tt> </tt><br>
        <font size="+1"><tt><font color="#3333ff"><b>Discover Kimchi
                peers&#65288;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>
          &nbsp; federation: enable|disable<br>
          }<br>
        </tt><br>
        <font size="+1"><tt><font color="#3333ff"><b>Migration&#65288;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&#65288;Sheldon Feng/Zhengsheng Zhou&#65289;[backend]</tt></b></font><font
          size="+1"><br>
          <tt><font color="#3333ff"><b>Asynchronous event
                notify&#65288;WenWang&#65289;[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>
          &nbsp; { "host":"127.0.0.1"<br>
          &nbsp;&nbsp;&nbsp; "port":"3260"<br>
          &nbsp; }<br>
          ]<br>
          <br>
          GET
/storageservers/&lt;server&gt;/storagetargets?_target_type=iscsi&amp;_server_port=&lt;port&gt;<br>
          [<br>
          &nbsp; {<br>
          &nbsp;&nbsp;&nbsp; "host":"127.0.0.1",<br>
          &nbsp;&nbsp;&nbsp;
          "target":"iqn.2003-01.org.linux-iscsi.localhost.x8664:sn.edb1a004dc57",<br>
          &nbsp;&nbsp;&nbsp; "target_type":"iscsi"<br>
          &nbsp; }<br>
          ]<br>
          <br>
          -----------<br>
          And thanks for your patience if you were reading this line
          now!&nbsp;<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>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <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>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>