[Kimchi-devel] Kimchi 1.3 Sprint 2 Overview

Mon Aug 18 06:31:16 UTC 2014

On 8/15/2014 1:44 AM, Aline Manera wrote:
> 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.

ISO file is big, I think the user need a way to cancel the upload/download.

>
> *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
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140818/9a0f6526/attachment.html>