[Kimchi-devel] Kimchi 1.3 Sprint 2 Overview

Aline Manera alinefm at linux.vnet.ibm.com
Thu Aug 14 17:44:28 UTC 2014


Hi all,

As agreed in the last scrum meeting 
(http://kimchi-project.github.io/kimchi/meetings/kimchi.scrum.2014-08-13-13.02.html), 
I am sending to you an overview about the sprint 2 tasks.
That way everyone can be aware of what is expected in each task and we 
don't block the UI development.

Just to make clear, this is my view on each task!
Maybe you - the task owner - have a different view on that. In this 
case, share your ideas with us.

And *don't forget to send a RFC, V1 patch, UI mockup *or something 
related to your task by *next Monday (08/18)*

This email is just a summary to motivate you! ;-)

*ISO pool: Support to download ISO from URL (vianac)*
The idea here is to provide a way to user download a ISO from URL to the 
OOTB pool (ISO pool)

POST /storagepools/ISO/storagevolumes/ {'name': <vol-name>, 'url': 
<http|https|ftp://url>}

- name can be optional. We can generate one automatically based on ISO 
path when any name is provided by user.
- url is required.

Questions:
- Which protocols will we support? http, https, ftp? Any other?

- About the UI, how do we show this feature to user?
   Basically we have 2 options:
   1) In the storage tab:
      Add an option "Add ISO" to the ISO pool (or any pool ?); get the 
URL and display a progress bar.
   2) While creating a template:
      Add an option "Download ISO"; get the URL and display a progress bar.
      When the download is completed, we create a template using the new 
ISO.

   I prefer the first option (storage tab) as it can also be used for 
upload ISO (see below)

*ISO pool: Support to upload ISO*
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.

POST /storagepools/ISO/storagevolumes/ {'name': <vol-name>, 'filepath': 
filepath}

For the UI we also have the same 2 options from downloading ISO from URL 
feature

I prefer the first one (storage tab) as we can use the same UI for both 
cases, download and upload.

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.

*Create template from VM (rotru)*
This will use the same backing storage mechanism used to create a 
template from a IMG file.

POST /templates {'name': <template-name>, 'vm': <vm-name>}

About the UI:
We have 2 options:
1) When creating a template:
    Add an option "From guest"; then list all guests to user choose one 
(or multiples ? ) and do the requests
2) On guests Actions menu
    Add an option "Create template" and do the request

I prefer the first option (while creating a template)

*Discover Kimchi peers(alinefm)*
This will use openSLP to register and discover Kimchi peers in the same 
network.

GET /peers will return the Kimchi peers
[{server: "https://1.2.3.4:8001"}, {server: "https://1.2.3.5:8001"}...]

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.

federation = enable|disable

When enabled, the kimchi server will be register in the openSLP tool and 
when requesting /peers we will search for peers

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."
To display that message, we need to update /config/capabilities to also 
return this info.

GET /config/capabilities
{ ...
   federation: enable|disable
}

*Migration(Simon Jin)*
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.
So I'd say I only expect to have the backend done for 1.3 release.

POST /vms/<name>/migrate {server: <other-kimchi-server-ip>}

*Asynchronous event notify(Sheldon Feng/Zhengsheng Zhou)[backend]*
*Asynchronous event notify(WenWang)[UI]*
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.
We have already started some discussion on ML "[Kimchi-devel] [RFC] 
Improve task management for kimchi" 
(http://lists.ovirt.org/pipermail/kimchi-devel/2014-June/006230.html)

*Authorization: Allow admin user change permission settings when VM is 
running (WenWang)
*The idea is display the same "Edit" dialog view when vm is running or not.
And when vm is running only enable the information that can be updated 
with running vm for editing.
That way we eliminate the "Manage Media" option and keep the UI 
consistent. And also provide a way to user checks the vm configuration 
(https://github.com/kimchi-project/kimchi/issues/387)

*VM ticket: update novnc/spice code (sheldon)*
POST /vms/<name>/connect will automatically set a random console 
password for the VM and sets its expiration time to 10 seconds later.
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.

*Display iSCSI targets when iSCSI server is provided (backend done in 
3c6c5c) (Yu Xin)*
It is similar to what we did for NFS servers. But in this case we will 
list the iSCSI targets for a given server.

GET /storageservers?_target_type=iscsi
[
   { "host":"127.0.0.1"
     "port":"3260"
   }
]

GET 
/storageservers/<server>/storagetargets?_target_type=iscsi&_server_port=<port>
[
   {
     "host":"127.0.0.1",
"target":"iqn.2003-01.org.linux-iscsi.localhost.x8664:sn.edb1a004dc57",
     "target_type":"iscsi"
   }
]

-----------
And thanks for your patience if you were reading this line now! :-)
I know it is a big email but it could not be different based on the 
tasks we have for sprint 2.

Feel free to use it as base for your RFC email.
I am looking forward to see all that done.

Regards,
Aline Manera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140814/be940ba5/attachment.html>


More information about the Kimchi-devel mailing list