<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <tt>Hi all,<br>
      <br>
      As agreed in the last scrum meeting
      (<a 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 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>
      &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><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><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 class="moz-txt-link-rfc2396E" href="https://1.2.3.4:8001">"https://1.2.3.4:8001"</a>}, {server:
      <a 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 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 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>
  </body>
</html>