[Kimchi-devel] Kimchi 1.3 Sprint 2 Overview

Mon Aug 18 14:30:52 UTC 2014

On 08/18/2014 03:56 AM, Yu Xin Huo wrote:
> On 8/18/2014 2:31 PM, Yu Xin Huo wrote:
>> 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.
>
> Aline, if it is named to be "Add ISO", then this action only apply to 
> that storage pool named "ISO".
> But upload/download is a generic functionality, I just think about 
> whether other storage pool also need it.
> Then we can name it to be 'Add Volume or Add File' to make this 
> upload/download to serve a broader scope.
>

ACK.

>>
>>>
>>> *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
>>
>>
>>
>> _______________________________________________
>> 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/cac2c72c/attachment.html>