13:04:13 <alinefm> #startmeeting
13:04:13 <kimchi-bot> Meeting started Wed Nov  5 13:04:13 2014 UTC.  The chair is alinefm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:04:13 <kimchi-bot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:04:13 <alinefm> #meetingname scrum
13:04:13 <kimchi-bot> The meeting name has been set to 'scrum'
13:04:29 <alinefm> #info Agenda 1) Status 2) Open discussion
13:04:29 <alinefm> anything else?
13:04:40 <royce> good
13:05:14 <alinefm> #topic Status
13:05:14 <alinefm> #info Please provide your status using the #info command: #info <nickname> <status>
13:05:26 <vianac> #info vianac sent patchset v1 for the clone feature; sent RFC for the snapshot feature; worked on the next patchset for the clone feature; worked on the snapshot feature; reviewed patches on the mailing list
13:05:40 <YuXin> #info YuXin Guest Clone UI v5
13:05:49 <wenwang> #info wenwang Finished Guest disk hot plug UI
13:06:00 <Guest512> #info Simon send out vm migration v1 patch to ML, working on v2 base  on comments from alinefm.
13:06:05 <alinefm> #info alinefm removed libxml2-python as Kimchi dependency and use lxml module to do XML manipulation
13:06:09 <danielhb> #info danielhb reviewed a dozen patches in the ML, sent patch set to edit disk type in the template, sent patch to add a new attribute to netinfo.get_interface_info
13:06:10 <royce> #info royce finished v1 patch of UI for ldap, rebased testcases for scsi cdrom found it not working for hotplug, abandoned
13:06:23 <wenwang> #info wenwang sent patch that redesign the template edit
13:06:31 <alinefm> #info alinefm refactor VMTemplate to use a common module to get guest disk XML
13:07:14 <alinefm> #info alinefm generate qemu commandline XML using lxml.builder
13:07:42 <alinefm> #info alinefm sent patches to fix some issues on featuretests.py
13:08:05 <alinefm> #info alinefm sent patches to refactor VMTemplate to use a common module to generate guest interface XML
13:08:37 <alinefm> #info alinefm sent patch to delete ui/js/modernizr.custom.2.6.2.min.js as it is not in use
13:09:15 <alinefm> anything else?
13:10:07 <alinefm> alright...
13:10:29 <alinefm> we have just more 2 weeks by the end of the devel phase (https://github.com/kimchi-project/kimchi/wiki/todo-1.4)
13:10:44 <alinefm> and we have a lot of unfinished tasks
13:11:08 <alinefm> so if you want your task to be on 1.4, you need to send patches ASAP to get review and merge in time
13:11:28 <alinefm> any of you think some task will not be completed on time?
13:11:51 <royce> Guest512, if you don't mind, I can take the set passwd UI, is that ok?
13:12:08 <Guest512> royce, that's great, thanks
13:12:29 <YuXin> I have concern about the new UI header
13:12:29 <alinefm> royce, but first, let's get LDAP merged
13:12:39 <alinefm> I mean, LDAP has high priority
13:12:45 <royce> sure, alinefm
13:13:04 <alinefm> YuXin, it is has low priority right now - so you can move it to the end of your todo list
13:13:26 <YuXin> ok, I will focus on the UI of serial console next
13:13:29 <Guest512> alinefm: peer(remote server)authentication still block vm migration
13:13:58 <Guest512> still have some issue with authentication via ssh
13:14:48 <alinefm> YuXin, I'd say to you send a mockup for snapshots
13:14:50 <Guest512> do you think it's possible that we will support peer authentication infra in kimchi in near future ?
13:14:57 <wenwang> What's the status of back-end of the adding disk from different storage pool?
13:14:57 <alinefm> vianac, do you think you can complete snapshots in 2 weeks?
13:15:04 <vianac> alinefm, yes
13:15:26 <alinefm> Guest512, what is the problem with the SSH authentication?
13:15:42 <wenwang> alinefm: Also, we shall talk about the iscsi volume choose when creating a VM
13:15:51 <alinefm> Guest512, do you mean user select a peer and provide its username and password to authenticate there?
13:16:14 <alinefm> rotru, do you have any update about "adding disk from different storage pool" ?
13:16:32 <Guest512> well, even 2 peers have ssh key exchanged, migration still failed due to failed authentication
13:17:20 <Guest512> and also libvirt remote connection still need password input manully
13:17:35 <alinefm> oO
13:18:11 <Guest512> i'm trying to figure how virt-manger do migration via ssh
13:18:35 <alinefm> it is a good start point
13:19:00 <alinefm> libvirt will always require a password to connect to it? or it depends on libvirt config?
13:19:24 <alinefm> I mean, after logging to server using hostname/password, it will always require a second password?
13:19:43 <alinefm> wenwang, yes - we can talk about it on open discussion
13:19:59 <alinefm> wenwang, did you do any investigation about the storage volume upload?
13:19:59 <wenwang> alinefm: sure
13:20:15 <alinefm> I really want to have upload enable on 1.4
13:20:28 <alinefm> *enabled
13:20:34 <wenwang> alinefm: Not yet. Just finished the template task. I will start tomorrow and update with my status
13:20:43 <alinefm> wenwang, great! thanks
13:20:52 <wenwang> alinefm: yw
13:21:59 <Guest512> alinefm: that best sulution is that use  sshpass -p to estiblish a ssh connection that libvirt can use it to connect a remote peer, but libvirt doesn't provide a API to reuse a ssh connection.
13:22:02 <royce> I will also help to look at upload, still working with LDAP things
13:23:28 <alinefm> ok - thanks
13:23:34 <alinefm> Guest512, got it
13:23:56 <alinefm> Guest512, I will try to do some investigation on it too and share what I find on ML
13:24:13 <alinefm> all: from my view the following tasks MUST be done by 1.4:
13:24:25 <alinefm> - SMT support (christy)
13:24:32 <alinefm> - Guest cloning (vianac)
13:24:33 <Guest512> thanks, i will send out a email later to provide some detail on this problem
13:24:43 <alinefm> - LDAP authentication support (royce)
13:24:52 <alinefm> Prevent disks from being added more than once to guest (christy)
13:25:06 <alinefm> - Fix and upload file to a storage pool（wenwang)
13:25:15 <alinefm> and the UI related to those backend tasks
13:25:34 <alinefm> The following tasks would be great to have if time permits us:
13:25:44 <alinefm> - Snapshot support (vianac)
13:25:52 <alinefm> - Live migration (simon)
13:25:59 <alinefm> what do you think about it?
13:26:51 <YuXin> I will look around these items and figure out how much UI content needed
13:27:00 <royce> cool with me
13:27:22 <vianac> fine with me
13:27:36 <wenwang> Fine with me
13:27:49 <alinefm> great!
13:28:04 <alinefm> any problem, just send an email on ML, ok?
13:28:30 <alinefm> so let's move on to open discussion
13:28:35 <alinefm> #topic Open Discussion
13:28:57 <alinefm> what do you have in mind for today?
13:29:49 <wenwang> alinefm: iSCSI volume choose when creating a VM
13:30:27 <alinefm> wenwang, yeap
13:30:47 <alinefm> as I said on ML I am a little afraid in moving it to VM because it may cause problems there
13:31:03 <alinefm> the vm creation process must always work
13:31:22 <alinefm> if we let user choose a volume there it will break the process
13:31:43 <alinefm> so I'd propose to use the shareable option when creating a vm using those volumes
13:31:51 <alinefm> then the reuse will not cause problems
13:32:30 <wenwang> alinefm: That means we don't need to change for current design?
13:32:30 <YuXin> but that disk maybe used as OS disk, right?
13:32:47 <alinefm> wenwang, correct
13:32:50 <alinefm> YuXin, yes
13:33:13 <YuXin> How can an OS disk to be shared?
13:33:14 <alinefm> YuXin, but kimchi always tries to boot the VM by disk and if any OS found in disks it fallback to cdrom
13:33:28 <alinefm> so we don't have problem in override a OS disk
13:33:45 <YuXin> after OS is installed
13:34:42 <YuXin> I mean OS is installed on the disk, then 2 vms will share one OS disk
13:35:04 <YuXin> OS will definitely write to that disk, so 2 VMs will write to the same disk?
13:37:27 <wenwang> Yeah, I have the same concern
13:37:49 <alinefm> yeap
13:38:30 <alinefm> the ideal solution would use the backingstore if the volume already has a OS
13:39:25 <alinefm> wenwang, YuXin, on backing store you have 2 disks to format 1: one is the base (read-only) and other is a new disk (read-write)
13:39:40 <alinefm> so the difference between the base / disk will be on read-write disk
13:39:42 <alinefm> makes sense?
13:40:08 <alinefm> royce, do you know if it is possible to do that ^with iscsi/scsi volumes?
13:40:17 <YuXin> I think when create vm from template, if it is iscsi or scsi fc, list volumes without OS for selection, why not this way?
13:40:57 <royce> alinefm, yes, I thought  we did that in ovirt before
13:41:37 <alinefm> YuXin, it will only until the template is used by first time
13:42:06 <YuXin> why only the 1st time?
13:42:25 <alinefm> once I used the template to create a vm, I installed an OS on this volume
13:42:36 <alinefm> on second time I will use the same template, the volume will have an OS
13:43:18 <YuXin> I mean list volumes in that iscsi or scsi pools for selection
13:43:33 <YuXin> if a volume already has an OS, it should be fitered out
13:45:05 <YuXin> so any vm created will use a different volume in that iscsi or scsi fc pool
13:45:22 <wenwang> Is it the fact that when user create an iscsi or scsi based VM, then the used volume could not be retrieved again?
13:45:58 <YuXin> yes, a volume already associated with a vm should be filtered out
13:46:02 <alinefm> I think using backing store will be the best solution for it - so we don't restrict user on volume selection
13:46:12 <alinefm> but I agree it will need time to do that
13:46:14 <wenwang> I mean from the response of the listStorageVolume, we cannot see the volume of iscsi/scsi for selection?
13:46:25 <YuXin> yes
13:47:42 <wenwang> Then it won't be a problem for adding the unused volume to the template cause once used we maynot get the response of it
13:47:42 <royce> alinefm, we may want to specify scenario when we want to create cow on readonly and when we just overwrite the original one
13:48:18 <alinefm> royce, we only create the cow if the base volume has an OS
13:48:27 <alinefm> I think we can use libguestfs to discover it
13:48:38 <alinefm> royce, the same you did for image files
13:49:21 <royce> since we are template based, why there are two disks with os and need to have cow?
13:50:30 <alinefm> let's say you configure a template to use iscsi volume X
13:50:49 <alinefm> if volume X does not have an OS on it, it will store the new OS from a fresh install, ok?
13:51:03 <royce> I mean, the scenario is: create a template base on a image, then add disk array, at this point, I found another disk has a os and want it have cow?
13:51:29 <YuXin> I am still trying to understand how it work, vm-1 is using a scsi volume as disk and change it along with time
13:51:55 <YuXin> vm-2 using this scsi volume as base and base is always changing unexpectedly
13:52:04 <alinefm> royce, do you mean allow user add disks used by other vms?
13:52:43 <royce> YuXin, once it becames base, vm-1 and vm-2 both use the base and write to copy on write disk, no one writing base
13:53:43 <royce> alinefm, we are not talking to this scenario? I suppose we are talking about adding scsi disk to a vm then found the scsi has a OS, is that so?
13:54:08 <alinefm> royce, I was talking on template level =)
13:55:13 <YuXin> if this way, 1) VM-1 need also use scsi volume as base. 2) copy on write will need a dir(default) volume. 3) finally, all scsi volumes will be used only as OS base disk along with time
13:55:25 <YuXin> I do not think this is user's objective
13:56:14 <alinefm> I had an idea =)
13:56:26 <YuXin> scsi volumes will have much better performance then other types of pools, by this way, I think it will impact vm performance.
13:56:33 <alinefm> look: we keep the template as it is
13:56:48 <alinefm> AND when listing the templates to create a new VM, we do a filter there
13:57:03 <alinefm> and if a template points to a use iscso volume we don't list it
13:57:14 <alinefm> so we make sure the just one vm will use it
13:57:19 <alinefm> what do you think?
13:57:50 <wenwang> I am okay with this solution
13:58:05 <YuXin> by this way, a scsi pool with 1000 volumes, then user need to create 1000 templates
13:58:07 <alinefm> we can use the "invalid" parameter for it
13:58:20 <alinefm> YuXin, or change the previous one
13:59:21 <YuXin> what is the difference between  volumes in scsi pool?
13:59:53 <YuXin> if no difference, just automatically pick one
13:59:54 <royce> size?
14:00:14 <royce> YuXin, only thing we concern is there would be already data in
14:00:16 <alinefm> size, format...
14:02:38 <YuXin> when vm using a volume as os disk, it will format it again, right?
14:03:01 <royce> Guys, my husband's sick and I need to take care of him, so I must get going, sorry
14:03:24 <alinefm> royce, please, go
14:03:27 <alinefm> YuXin, no
14:03:32 <alinefm> the disk size keeps as it is
14:03:35 <royce> thanks alinefm, bye guys
14:03:44 <wenwang> see you royce
14:03:49 <YuXin> ok, so we need to ask user to select scsi volume
14:04:36 <alinefm> YuXin, does it mean you agreed with the filter template on VM creation?
14:04:44 <YuXin> ok
14:05:05 <alinefm> I will check the API and see if needs some change on backend
14:05:12 <alinefm> I have 2 more topics
14:05:21 <alinefm> I hope they are simpler =)
14:05:43 <wenwang> alinefm: great
14:06:20 <alinefm> baude asked me about this file: ./ui/libs/modernizr.custom.76777.js
14:06:28 <alinefm> YuXin, wenwang, do we really need it?
14:06:53 <YuXin> I have no idea about this file
14:07:04 <YuXin> can you copy some content in it?
14:07:25 <wenwang> alinefm: I don't know about this
14:07:30 <alinefm> it is an imported file
14:07:43 <alinefm> I also don't have any idea about its content
14:08:07 <alinefm> YuXin, wenwang, may I remove it and test Kimchi UI and if no change remove it from Kimchi?
14:08:12 <YuXin> http://modernizr.com/
14:09:34 <YuXin> aline, all the browsers kimchi support already support html5 and css3 I think
14:09:44 <alinefm> YuXin, me too
14:09:56 <alinefm> so apparently no problem in removing it, right?
14:10:01 <YuXin> so this file does not needed any more
14:10:07 <YuXin> if there is no reference to it
14:10:21 <YuXin> so just remove it and do a testing, if no error, then it is ok to remove it
14:10:33 <alinefm> great! thanks
14:10:47 <alinefm> other topic: about the clone pre-check
14:10:58 <alinefm> I started doing some code and faced a problem
14:11:08 <alinefm> a vm disk may not be in a pool
14:11:32 <alinefm> in that case, I'd return pool=''
14:11:36 <alinefm> makes sense?
14:11:47 <alinefm> so on pre-check those disks would be ignored
14:12:17 <YuXin> if the disk has no pool, then it will be cloned on default pool?
14:12:30 <alinefm> vianac, ^
14:13:09 <YuXin> I think we can only clone it to default pool
14:13:15 <vianac> maybe
14:13:24 <vianac> I haven't found a case when a disk is not in a pool
14:13:48 <alinefm> you can manually edit your vm XML to test it
14:14:19 <alinefm> vianac, did you test the clone feature with a vm using backingstore?
14:14:23 <YuXin> ok, since it will definitely copy to default pool, then pre-check should ignore it
14:14:47 <alinefm> or check the default pool has enough size to this new cloned disk?
14:15:23 <YuXin> if default pool does not have enough space, then an error will be responsed
14:15:45 <vianac> alinefm, what's backingstore?
14:16:05 <alinefm> vianac, a volume composed by base and cow image
14:16:19 <alinefm> vianac, you get one when creating a vm from a image file template
14:16:54 <vianac> alinefm, so I did, and the VM is cloned to the default pool
14:17:14 <alinefm> vianac, and did you start the clone vm?
14:17:15 <vianac> actually, the original VM disk is already in the default pool, it's not different for the clone process
14:17:31 <vianac> err, no.
14:17:34 <vianac> I will test it
14:17:35 <vianac> :P
14:17:45 <YuXin> base should not be copied, and backingstore should be copied to the same pool
14:17:53 <alinefm> YuXin, yeap
14:17:58 <alinefm> vianac, so test it, please
14:18:06 <alinefm> the base will not be cloned, only the cow file
14:18:34 <alinefm> ok team
14:18:39 <alinefm> anything else for today?
14:19:10 <alinefm> ok.. sorry about the time again =$
14:19:15 <alinefm> thanks everyone for joining
14:19:26 <alinefm> #endmeeting