13:01:11 <alinefm> #startmeeting
13:01:11 <kimchi-bot> Meeting started Wed Dec  4 13:01:11 2013 UTC.  The chair is alinefm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:11 <kimchi-bot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:01:18 <alinefm> #meetingname scrum
13:01:18 <kimchi-bot> The meeting name has been set to 'scrum'
13:01:18 <royce> hi, danielhb, alinefm, shall we start now?
13:01:39 <alinefm> #info  Agenda 1) Sprint 2 2) Open discussion
13:01:43 <alinefm> royce, yes
13:01:48 <alinefm> anything else?
13:02:33 <alinefm> seems not
13:02:53 <royce> markwu:gerrit?
13:03:07 <shaohef> it's ok for me
13:03:19 <markwu> royce, yes, if you have interest
13:03:29 <markwu> i have sent an email
13:03:55 <alinefm> royce, markwu, I think we can cover it on open discussion section
13:04:03 <markwu> agree
13:04:16 <royce> sure
13:04:28 <alinefm> so let's get started
13:04:31 <alinefm> #topic Sprint 2
13:04:42 <alinefm> https://github.com/kimchi-project/kimchi/wiki/Todo-1.1
13:04:51 <shaohef> gerrit is a platitude.  cons and pros  between mail-list and gerrit.
13:05:02 <alinefm> the first item is: Basic host management (host)
13:05:16 <alinefm> I've just seen the UI patches related to it on mail list
13:06:06 <shaohef> alinefm: I have test it today.
13:06:06 <alinefm> and in my first tests it seems ready to be merged
13:06:15 <shaohef> alinefm: agree.
13:06:40 <alinefm> what is missing about this item is about: Backend and API to initiate shutdown and reboot
13:06:42 <alinefm> rotru, ^
13:06:46 <alinefm> any update?
13:07:15 <ming> shutdown is a pretty dangerous operation, we should take care.
13:07:27 <ming> Also as reboot
13:08:05 <rotru_> alinefm; hi
13:08:12 <ming> Also, I think shutdown is not clear enough to me, does it mean power off or machine halt?
13:08:31 <alinefm> ming, power off
13:08:57 <ming> power off is more exact than shutdown.
13:08:59 <alinefm> ming, when authorization comes to board those operations will be restricted to admin user
13:09:33 <ming> shutdown can be just a halt with power on.
13:09:55 <rotru_> alinefm; ming  I modified the patches in order to just allow shutdown/reboot when none vm is in running state
13:10:31 <rotru_> so, for now, admin will have to stop vms manually before stop server
13:10:38 <alinefm> rotru, ok
13:10:59 <rotru_> I would like to implement vms save/restore in the future
13:11:00 <alinefm> rotru, and when will you send the next version to mail list?
13:11:10 <pvital_> IMO, thereis no impediment to reboot/shutdown the host with VM's running. we just need alert the user/sys_adm and save/restore the VMs
13:11:15 <alinefm> rotru, pradeep sent patches for it
13:12:36 <alinefm> rotru, and when will you send the next version to mail list?
13:13:07 <rotru_> alinefm;  I am trying to test mock , then patch should be read after
13:13:23 <shaohef> we should save all VM and then shutdown or reboot?
13:13:23 <shaohef> now, maybe should not allow power off if there is a vm is living.
13:13:23 <shaohef> after we support save VM, kimchi can save VMs first and then shutdown.
13:13:23 <alinefm> rotru, do you think it can be done by today?
13:14:09 <alinefm> shaohef, for now, we just reboot and shutdown when no vm is running
13:14:22 <zwu> shaohef: thanks for your info, i will have to go to the office and talk to my boss.
13:14:22 <alinefm> when we implemente save/restore we can improve it
13:14:29 <ming> shaohef, right. The vm user should not notice VM's off and on.
13:14:56 <ming> that is our next step
13:15:28 <alinefm> ming, agree
13:15:39 <rotru_> alinefm; ming , shaohef  yes! vm shutdown, save, restored will be a improvement in next version
13:15:44 <shaohef> alinefm:  agree.
13:15:51 <alinefm> ok
13:15:52 <shaohef> zwu: you are welcome.
13:15:52 <shaohef> ming: yes.
13:16:00 <alinefm> next: Storage: New Storage Pool based on local disk (storage)
13:16:03 <alinefm> danielhb, ^
13:16:29 <alinefm> I tried your patches yesterday and got some errors
13:16:48 <zhoumeina> hello
13:16:53 <danielhb> alinefm, errors apparently are fixed now, I'll sending v6 shortly
13:17:05 <alinefm> danielhb, great
13:17:12 <danielhb> alinefm, but I'm tempted to send them to you first to see if they are really working now :)
13:17:35 <ming> danielhb, don't be shy to send out to all of us.
13:17:49 <ming> We can do more tests.
13:17:57 <danielhb> ming, that's because alinefm's notebook does not like me and keeps crashing my stuff
13:18:03 <alinefm> hehehe
13:18:09 <danielhb> ming, but I'll send them all to you, of course :)
13:18:13 <alinefm> my notebook is terrible =)
13:18:20 <ming> alinefm is using unbutu?
13:18:25 <royce> I saw zhshzhou commented about using exsited VG
13:18:37 <alinefm> alinefm, yes
13:18:41 <alinefm> ming, yes
13:18:47 <alinefm> zhoumeina, I've seen your patches about the UI for it but I haven't had chance to check it yet
13:18:55 <alinefm> zhoumeina, do you want to comment something about it?
13:19:19 <danielhb> royce, I was going to answer that ... I think this is already supported if you use an existing VG as target while providing no devices in the <source> element
13:19:36 <zhoumeina> alinefm: yes, in this patch I also changed the nfs style
13:20:15 <royce> OK, so provide a VG name can cover that, right? danielhb
13:20:19 <danielhb> royce, but this is a guess based on what I've read on Red Hat documentation on virt-manager (please do not ban me!), need to test it to see if this works
13:20:27 <zhoumeina> I changed storage pool type to list box
13:20:27 <alinefm> zhoumeina, you made a single window and dynamically show more inputs according to pool type?
13:20:40 <zhoumeina> alinefm: yes
13:21:17 <alinefm> zhoumeina, ok - I will try them after meeting
13:21:19 <royce> danielhb, yes, guess that'll work cause libvirt doc said so too.
13:21:53 <alinefm> next: Add new yum repository (from ISO and from URL) (host)
13:21:55 <alinefm> pvital_, ^
13:22:13 <zhoumeina> create storage pool,user will see the "dir" page.when he/she change the storage type, different input can be seen
13:22:53 <alinefm> pvital_, you sent the patches about YUM repo at the begging of the week, any update?
13:22:54 <pvital_> alinefm, I submited this morning a new version to API and backend. It's supporting YUM for now because I found some errors in different versions of python-apt
13:23:38 <pvital_> I'm testing e re-implementing the APT support.
13:23:41 <alinefm> pvital_, are you considering an repo as a ISO file?
13:24:29 <pvital_> alinefm, from ISO I assumed that is already mounted
13:24:41 <ming> pvital, I am not understanding how you can use yum update when you don't pass password to RHEL repoitory
13:24:48 <pvital_> so you can use the file:// os mount point
13:25:03 <ming> I think all of the RHEL repository are protected by password and user.
13:25:24 <alinefm> ming, epel is not protected
13:25:46 <alinefm> pvital_, ok
13:25:58 <alinefm> pvital_, do you have an idea when apt support will be done?
13:26:39 <pvital_> ming, yes and no! once the sys_adm uses the rhn_reg (or something else) it's not necessary user/password. Yum has the repositories info stores and it'll be reflected in out list
13:26:39 <shaohef> alinefm:  I have seen pvital_ add file:// for iso file
13:26:48 <shaohef> pvital_: right?
13:26:59 <pvital_> alinefm, I guess until the end of day
13:27:11 <ming> Do you have plan to use offical RHEL repository, like Redhat RHN, LTC ftp3?
13:28:04 <pvital_> ming, I guess we can improve this in later versions. For now I'm supporting only public repositories
13:28:19 <ming> Sure, that is clear.
13:28:50 <ming> for iso file, will you check it is a valid iso?
13:30:06 <pvital_> ming, what do mean by 'valid iso' ?
13:30:25 <pvital_> bootable? linux content?
13:30:49 <ming> For example, the user need to update FC19,  but in the host only FC18 iso is mounted.
13:31:32 <ming> So the user may input FC18 path for yum.
13:31:49 <ming> But that is not what you expected.
13:32:03 <pvital_> ming, no! I'm not checking this kind of info!
13:32:28 <ming> So you assume the iso file is right and mounted already.
13:32:40 <pvital_> yes
13:33:18 <alinefm> next?
13:34:19 <pvital_> alinefm, go ahead
13:34:27 <alinefm> ok
13:34:28 <alinefm> Software update (host)
13:34:39 <alinefm> pvital_, you again ^
13:34:47 <pvital_> alinefm, :-D
13:35:36 <pvital_> alinefm, I have it implemented but need APT support first! then I'm going to test it and submit
13:35:39 <ming> softwware update depend on new yum  repository?
13:35:50 <pvital_> I guess I can finish this today
13:36:06 <pvital_> alinefm, BTW ramonn implemented the core of this issue!
13:36:09 <pvital_> thanks ramonn
13:36:21 <pvital_> s/issue/feature
13:36:30 <pvital_> ming, no
13:36:42 <ramonn> pvital_, if you need help, just call me
13:36:46 <alinefm> ming, the software update can work with the current repos
13:36:49 <ming> Is it not updated by yum or apt?
13:37:07 <alinefm> ming, yes
13:37:25 <alinefm> pvital_, you can include ramonn as signed-off on patches
13:37:35 <pvital_> alinefm, for sure
13:37:45 <ming> alinefm, current repos means the default repos coming with the Linux distros?
13:38:09 <alinefm> ming, yes
13:38:22 <alinefm> or other repos admin added manually
13:39:01 <pvital_> alinefm, I guess I got what ming wants to understand.
13:39:15 <pvital_> I did a dependency between these two features
13:39:35 <pvital_> but looking ming questions, I see it can be independents
13:40:21 <pvital_> alinefm, will work with ramonn to send a patch that dont depends on (new) repositories feature
13:40:48 <alinefm> pvital_, it'd be great
13:41:10 <ming> pvital_, cool.
13:41:13 <pvital_> ramonn, you have 10min to implement it
13:41:16 <pvital_> :-D
13:41:20 * pvital_ is evil
13:41:30 <alinefm> ok, I think we pass through all the tasks
13:41:35 <alinefm> so we have:
13:42:00 <alinefm> #action rotru send patches about reboot/shutdown to mail list by today
13:42:24 <alinefm> #action pvital_ send patches to yum/apt patches by today
13:42:46 <alinefm> #action pvital_, ramonn  send patches to software update by today
13:42:51 <alinefm> is that right?
13:44:00 <rotru_> alinefm;  ok
13:44:00 <ming> Do you guys get power machines to test Kimchi on power?
13:44:31 <pvital> alinefm, I don't know how is that pvital_
13:44:32 <pvital> :-D
13:44:46 <pvital> just kidding! to relax a bit!
13:45:04 <markwu> :)
13:45:06 <alinefm> pvital, =)
13:45:08 <alinefm> ok
13:45:16 <alinefm> then open discussion
13:45:22 <alinefm> #topic Open Discussion
13:45:25 <shaohef> pvital:  who is pvital_ ?
13:45:36 <alinefm> shaohef, it is pvital clone =P
13:45:36 <ming> gerrit server setup?
13:45:41 <alinefm> ming, sure
13:45:51 <alinefm> I've just read the mail sent by markwu
13:45:54 <ming> I think we need a server with public access.
13:46:01 <alinefm> ming, exactly
13:46:03 <pvital> shaohef, alinefm: and he is evil !!!
13:46:06 <danielhb> shaohef, pvital_ is the IRC client that pvital keeps online inside the Mercedes
13:46:18 <ming> It seems that oVirt may host Kimchi gerrit server for us.
13:46:28 <markwu> ming, at first, I would like to get agreement among our community about the change
13:46:38 <alinefm> and more than that we need to think how it will improve our process
13:46:52 <ming> markwu, no one object it yet.
13:46:59 <alinefm> I agree with markwu points about CI and etc
13:47:02 <markwu> if everyone is fine with this proposal,  we can consider to resolve the public server
13:47:09 <alinefm> but my concern is about reviewing itself
13:47:34 <pvital> markwu, alinefm: let's vote here?
13:47:44 <alinefm> pvital, no
13:47:45 <markwu> alinefm, anyway, as a tool,  gerrit is better than mailling list
13:47:46 <alinefm> let's discuss
13:47:46 <ming> alinefm, gerrit record the reviewing process quite well.
13:47:49 <alinefm> =)
13:47:54 <royce> alinefm, reviewing it self?
13:47:54 <shaohef> I think adam and anthony do not like gerrit, just because the are used to mail-list.
13:47:54 <shaohef> they use mutt as their mail client.
13:47:54 <shaohef> adam suggests Evolution.
13:47:54 <shaohef> Evolution is better than thunderbird  for code review.
13:47:54 <shaohef> also mutt can use vim as it editor.
13:47:55 <shaohef> mutt and Evolution can support highlight.
13:48:15 <shaohef> but most of us use thunderbird
13:48:18 <markwu> even though gerrit can't resolve all the problems
13:48:36 <pvital> +1
13:48:42 <ming> +1
13:48:49 <alinefm> markwu, when any new patch is sent to gerrit, how all the team is notified?
13:49:24 <markwu> alinefm, if you need the notification,  gerrit can send a mail automatically
13:49:53 <alinefm> markwu, so each you need to configure gerrit to it?
13:49:54 <shaohef> then gerrit can send it to every one?
13:49:57 <markwu> but according to the experience before,  people normally just focus on the dashboard of gerrit
13:49:58 <ming> alinefm, it can also be configured to send the notification to the mailing list.
13:50:11 <rotru_> one person will have to be like a Gerrit manager, reviewing all stuff a
13:50:13 <markwu> yes
13:50:37 <rotru_> actually , alinefm  =P
13:50:41 <ming> Also, a person can be assigned to the patch to do review.
13:50:42 <markwu> http://gerrit.ovirt.org/#/q/status:open+project:vdsm,n,z
13:50:47 <alinefm> ming, no
13:50:49 <royce> alinefm, we add ourselves as reviewer for mail notification, or we go to website for review
13:50:50 <markwu> here's an example of gerrit
13:50:58 <markwu> yes
13:51:12 <markwu> royce, good point!
13:51:25 <pvital> cant be the mailling list?
13:51:35 <markwu> it can get your attention when the patch is updated.
13:51:44 <ming> alinefm, a person can be assigned, while others can also do the review.
13:51:54 <markwu> and you also can add reviewer request on your patch
13:51:59 <ming> alinefm, thet is not exclusive.
13:52:02 <pvital> or a different mailing list, like kimchi-gerrit ot kimchi-dev
13:52:09 <danielhb> I don't understand what't the difference of gerrit review vs what we do in the mailing list ... but we can try using gerrit, of course
13:52:16 <royce> normally we use the later one, that is kind of like browsing bbs,quite convinient
13:52:46 <royce> pvital, danielhb, difference is we can test others patch easier
13:52:54 <markwu> it also provides a clear view of patch diff
13:53:00 <danielhb> I was commiter of a open source project called Linuxtools (an Eclipse.org project) and we switched to Gerrit there .... I didn't saw any difference but the extra stuff to do before commit/push
13:53:25 <markwu> even for  differences among revisions of one patch
13:53:47 <danielhb> but, again, let's try gerrit and see if that improves the review process here ... if it doesn't, roll back :)
13:54:47 <alinefm> danielhb, we need to do it carefully
13:54:50 <royce> maybe 1 week trial period?:)
13:54:57 <alinefm> I am not convinced it will be good for us
13:54:59 <shaohef> royce:  how can we test others patch easier. git pull other's patches?
13:55:15 <royce> shahef:git fetch git://gerrit.ovirt.org/ovirt-engine refs/changes/37/20737/20 && git checkout FETCH_HEAD
13:55:32 <pvital> piece of cake!
13:55:34 <pvital> :-D
13:55:48 <shaohef> royce:  recall it.
13:55:48 <royce> it has origin ref for commit change
13:55:58 <ming> royce, that is pretty nice for us.
13:56:00 <alinefm> and why not: git am <mail-patches>?
13:56:19 <ming> alinefm, you need to downlaod mail-patches first.
13:56:41 <pvital> and send to some machine it's configured to use mail
13:56:43 <alinefm> ming, there tools to make it for you
13:56:56 <royce> alinefm, his patch is diff from his tip, so when applying on your tip, there will be conflict you need to resolve
13:57:00 <ming> However, for gerrit, just one command.
13:57:27 <shaohef> alinefm:  most of us use thunderbird, thunderbird is not convinient to download patches.
13:57:38 <alinefm> ming, make a script and get it in one command
13:57:47 <royce> alinefm, you can to review for openstack, then you will know how it works and love it:)
13:57:58 <alinefm> shaohef, I also use thurderbird and it works weel for me
13:58:17 <markwu> alinefm, is it friendly for the guys not deeply use linux command lines?
13:58:19 <alinefm> royce, yes - I think I need to try it out to change my view of it
13:58:43 <royce> hehheh, OK, after you tried, we can get a conclusion, OK?
13:58:45 <alinefm> markwu, how a non-linux devel will code for linux?
13:58:45 <markwu> I believe the guys from software group doesn't like that resolution
13:58:46 <shaohef> alinefm: you can share your script
13:58:57 <shaohef> alinefm:  linux expert like mail-list, like anthony.  most of us are not linux expert
13:59:21 <alinefm> let's do that way
13:59:29 <markwu> alinefm, are zhoumeina YuXin contributing to kimchi?
13:59:37 <alinefm> I think some people here already tried out gerrit and liked it
13:59:45 <alinefm> others don't like it so much
13:59:53 <alinefm> and others don't try it yet
14:00:18 <alinefm> I can get a conclusion before try it
14:00:31 <royce> We won't push~ just have a try and we can help if you have problem with that, OK?
14:00:36 <alinefm> I will install it in my system and check how it works and how it can improve our process
14:00:56 <markwu> alinefm, you don't need install it on your system
14:01:07 <markwu> you could just try it with ovirt or openstack
14:01:11 <shaohef> alinefm:  but I'm interesting in your thunderbird script. can you share it with us?
14:01:13 <markwu> it's already there
14:01:31 <alinefm> shaohef, sure
14:01:49 <markwu> alinefm, how you do a incremental review of patch?
14:01:50 <shaohef> alinefm: great.  thanks.
14:01:54 <alinefm> I used patches program from Anthony: https://github.com/aliguori/patches
14:02:44 <alinefm> markwu, what do you mean with incremental review?
14:02:55 <alinefm> V2, V3?
14:03:04 <markwu> alinefm, actually I don't strongly insist on gerrit for review, but for CI
14:03:08 <markwu> yep
14:03:09 <shaohef> alinefm: it looks good.
14:03:34 <markwu> you have to maintain different patches on your local branches
14:03:44 <alinefm> markwu, I agree the CI part is awesome
14:04:16 <alinefm> markwu, but I am wondering if we can get it just using jenkins
14:05:23 <shaohef> alinefm:  jenkins can work without gerrit.
14:05:39 <alinefm> shaohef, yes
14:05:45 <markwu> pvital, any idea?  maybe we can write a script to monitor the mailing list , download the patch to test and then post a notification if it fails
14:05:51 <alinefm> I mean if jenkins can cover the CI part done by gerrit
14:06:24 <pvital> markwu, it's possible
14:06:45 <alinefm> markwu, this script already exists! https://github.com/aliguori/patches
14:06:46 <alinefm> =)
14:06:48 <markwu> pvital, yes, it's possible. but
14:06:51 <pvital> hadoop and other apache projects use this approach
14:07:34 <markwu> ok, then we can follow their practice
14:07:57 <pvital> hadoop uses jenkins to get the patches (but submitted to a issue tracking system) and test it over trunk/master
14:08:12 <markwu> can it fetch every post patch or every merged patch?
14:08:16 <pvital> we can use the same idea
14:08:41 <markwu> pvital, we should run the test before patch merged
14:09:20 <markwu> it should be a proof of that the patch is valid for maintainer ( alinefm)
14:09:58 <pvital> markwu, yeap!
14:10:16 <alinefm> yes
14:10:21 <markwu> pvital, ok. that's great
14:10:42 <alinefm> look I didn't say NO to gerrit
14:10:57 <alinefm> as I said I will try it to check how it works
14:11:08 <alinefm> then we can discuss in next scrum meeting
14:11:19 <markwu> ok. actually my concern is we can't request a public server
14:11:38 <markwu> but for jenkins,  we could run in behind IBM firewall
14:12:07 <alinefm> now we are part of ovirt community so we could ask ovirt for it
14:12:09 <markwu> it's not good, but still work
14:12:17 <markwu> hope so
14:13:02 <alinefm> ok
14:13:06 <alinefm> #endmeeting