Re: [Kimchi-devel] Kimchi 1.3 Sprint 2 Overview

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-1...), > 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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel