[Kimchi-devel] Kimchi 1.3 Sprint 2 Overview

Mon Aug 18 14:30:00 UTC 2014

On 08/18/2014 12:02 AM, Royce Lv wrote:
> On 2014?08?15? 01:44, 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.
>
> I personally prefer POST /storagepools/ISO/storagevolumes/upload then 
> just POST to collection:
> Reasons are:
>     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.
>     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.
>        So to make the REST API match its function, I prefer to use 
> "POST upload".
>
> For download it is the same.

ACK.

Cristian, please do the same for 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/c93f290c/attachment.html>