<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 & 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':
<vol-name>, 'url': <http|https|<a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="ftp://url">ftp://url</a>>}<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':
<vol-name>, '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': <template-name>, 'vm':
<vm-name>}<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/<name>/migrate {server:
<other-kimchi-server-ip>}<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/<name>/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/<server>/storagetargets?_target_type=iscsi&_server_port=<port><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>