13:02:17 <alinefm> #startmeeting
13:02:17 <kimchi-bot> Meeting started Wed Jan  8 13:02:17 2014 UTC.  The chair is alinefm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:17 <kimchi-bot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:02:21 <danielhb> yo
13:02:24 <alinefm> #meetingname scrum
13:02:24 <kimchi-bot> The meeting name has been set to 'scrum'
13:02:29 <royce> Hi guys~shaohe's on his way back home, may delay participating
13:02:41 <alinefm> #info  Agenda 1) Sprint 1 status 2) Open discussion
13:02:45 <alinefm> anything else?
13:02:56 <alinefm> royce, thanks for share it
13:02:57 <ming> power shedule?
13:03:08 <royce> alinefm, yw
13:04:06 <alinefm> ming, it is not in the community scope
13:05:36 <alinefm> #topic Sprint 1 status
13:05:40 <alinefm> As we are doing, please provide your status using the #info command: #info <nickname> <status>
13:06:30 <ming> sprint is ending.
13:06:44 <zhoumeina> #info UI patches for iSCSI pool, I just send v6
13:06:55 <alinefm> #info alinefm Patches related to isoinfo refactoring were merged
13:07:33 <royce> #info royce  status: storage targets probe, almost done, fixing problem of GET param to cover more scenario, will send new version tonight
13:07:38 <alinefm> #info alinefm I am still working on model/mockmodel refactoring. I hope sending patches at the beginning of next week
13:08:23 <royce> #info royce asks to add "cdrom add/changemedia support" to sprint 2, RFC submitted, @alinefm
13:08:58 <zhoumeina> #info zhoumeina iSCSI patches is ready to go
13:09:09 <alinefm> royce, I will take a look in it
13:09:16 <royce> thanks
13:09:28 <rotru> #info rotru FC/SCSI feature: The backend API to create the SCSI pool is done. I am currently hacking the vm creation process to use SCSI Luns as disks.
13:10:13 <YuXin> #info customize of jquery-ui widget in use is completed
13:10:24 <ming> rotru, why hacking? Is there more graceful way to do that?
13:10:53 <royce> #info shaohe's customise network for template is merged, now he's working on permission checking and report attatched vm information on a network
13:11:08 <alinefm> YuXin, I think there are some patches that need review
13:11:13 <zhoumeina> alinefm: I hope you can review iSCSI UI later, it is already reviewed by zengsheng
13:11:25 <alinefm> YuXin, zhoumeina, as you may know I am not UI expert so I would like you reviewing them
13:11:36 <YuXin> ok
13:11:58 <zhoumeina> ok, we can review each other's patch
13:12:04 <YuXin> mei na, I have reviewed some of your patch with comments
13:12:36 <alinefm> zhoumeina, YuXin, of course, I also review the UI patches but I think you can do a better review than me
13:12:54 <rotru> ming; no no, I am not changing everything .... I am adding a new functions if the pool is SCSI type ... then I need to change the flow ...thats why I said I am "hacking"
13:13:04 <YuXin> ok, mei na, let us review Ui patch in pair tomorrow to get all ui patch reviewed tomorrow
13:13:11 <ming> #info Design UI removal V2  is calling for review.
13:13:13 <zhoumeina> YuXin: ok
13:14:05 <alinefm> anyone has blockers?
13:14:26 <ming> rotru, not sure If I understand wht a SCSI poo is?  Do you mean FC storage pool?
13:14:36 <rotru> ming; yes
13:15:11 <rotru> alinefm; actually, I do not have good resources to test FC functionality
13:15:40 <ming> Rotru, So the block device link of the storage volume in the FC storage poll will be passed to qemu directly?
13:15:41 <rotru> ming;  FC is a subtype of SCSI
13:16:08 <alinefm> rotru, what do you need? a machine with FC?
13:16:09 <ming> s/storage poll/storage pool
13:17:06 <rotru> ming, I think so
13:17:45 <rotru> ming; actually, libvirt is going to handle the block device
13:18:37 <christyp> rotru: i might have a system in the austin lab that's using fc that you can test with
13:18:38 <pvital_> rotru, that x86_64 box I told you is not working for your tests?
13:19:07 <rotru> alinefm;  a machine with latest libvirt , connected to a FC storage (directly, and through a SAN)
13:19:43 <rotru> christyp; thats nice!
13:19:56 <rotru> pvital_; not sure what box you are talking about
13:20:07 <alinefm> rotru, did you check is there is a way to pass the FC from the host to a vm? so we can create a vm for each supported distro and test in vm
13:20:12 <alinefm> nested virtualization
13:21:28 <rotru> alinefm; good point, I would have to pass the scsi device to the VM ... not sure if this is possible
13:21:40 <rotru> alinefm;  will check it
13:22:00 <alinefm> we can try it after meeting
13:22:11 <alinefm> and also check the machine christyp mentioned
13:22:25 <AdamKingIT> I think we want NPIV, which is a pending requirement for Kimchi too
13:22:52 <rotru> AdamKingIT; really ?
13:23:21 <AdamKingIT> I am the last person to even play a FibreChannel expert even on TV, but I think so...
13:23:29 <AdamKingIT> http://en.wikipedia.org/wiki/NPIV
13:24:22 <rotru> AdamKingIT; I see
13:24:59 <AdamKingIT> might allow us to allocate a FC port to each of the guests hosting the diff distros
13:25:27 <alinefm> AdamKingIT, yeap! it can help us on testing
13:27:04 <alinefm> ok
13:27:14 <alinefm> so I would like everyone to open the kimchi wiki: https://github.com/kimchi-project/kimchi/wiki/Todo-1.2
13:28:00 <alinefm> from all the sprint 1 tasks planned we have jus a few ones merged, other partial completed and other with patches on mail list
13:28:07 <pradeep> alinefm: havent added image_formats ( qcow2, raw, ..etc) to sprint list
13:28:45 <pradeep> working on it. will send patches by end of the week
13:28:48 <alinefm> pradeep, not yet
13:28:58 <alinefm> pradeep, we can add it for sprint 2 or 3
13:29:16 <pradeep> alinefm: ok
13:29:37 <alinefm> so I would like to hear from all of you why we need to change to get all tasks planned merged
13:30:06 <alinefm> look, I am not blaming anyone, I am just trying the identify what we are doing wrong to do better for next sprints
13:30:46 <ming> http://tools.cherrypy.org/wiki/RestfulAuth
13:31:06 <ming> Not sure who gave this link on the wiki page.
13:31:14 <alinefm> ming, me
13:31:34 <ming> That is not what I had though before.
13:31:44 <ming> s/though/thought
13:32:02 <alinefm> rotru, royce, christyp, zhoumeina, YuXin, any idea?
13:32:26 <royce> For me, during sprint some other tasks and ideas jumped in~
13:32:29 <alinefm> ming, we can talk about it in open discussion section
13:33:24 <royce> And sometimes, blockers not solved as I expected, such as Ubuntu bug, I spent half week to solve it, which I assume libvirt works right
13:33:47 <royce> That's reasons from my perspective~
13:34:05 <YuXin> so some initial investigation is needed before planning
13:34:06 <zhoumeina> alinefm: First I have to say that sprint 1 is short.And we have patches depending on others.
13:34:39 <rotru> alinefm; I prioritized my tasks  wrongly ...
13:34:53 <rotru> alinefm; so, need to pay more attention on this
13:35:40 <alinefm> anyone think it is also about few reviews and long time patches pending on mail list?
13:36:05 <christyp> rotru: alinefm, maybe that's a good word. is there any order or priority to the things in the sprints?
13:36:29 <royce> Right, alinefm, we need to speed up to help others review~
13:37:34 <alinefm> christyp, not for each sprint
13:37:43 <rotru> alinefm;  if you/community want every task merged in last day of the sprint, then, all patches must be sent to the review at least one week before
13:38:05 <alinefm> agree
13:38:06 <AdamKingIT> prev releases we had them mostly ordered, maybe that would help again though
13:38:08 <rotru> alinefm; review and test take time
13:38:41 <AdamKingIT> with most people having only 1 item, its kind of a personal list of 1
13:38:43 <alinefm> when looking for the tasks on sprint 1 I thought all those could be done in 3 weeks
13:39:10 <alinefm> 1 week for devel, 1 for review and adjustments and 1 to get it merged
13:40:08 <alinefm> but as royce mentioned there is some kind of problems we can't predict
13:40:20 <ming> alinefm, sometime we need more communications to know the size of the items.
13:40:22 <AdamKingIT> I think we might split the 3 weeks alittle differently
13:41:19 <alinefm> AdamKingIT, go ahead
13:41:37 <christyp> AdamKingIT: #agree. something more "agile" and less "waterfall"
13:41:46 <AdamKingIT> maybe 0.5 mock, 0.5 review,  1 dev, 0.5 review, 0.5 merge
13:42:27 <AdamKingIT> I'd hate to spend a week implementing the 'wrong' design, whether that be API or UI
13:43:13 <royce> agree, and some opinion comming at the version you thought it should be merged
13:43:27 <alinefm> agree! also the RFC is very welcome
13:43:32 <AdamKingIT> Goal is to get things visible earlier and validated with the community
13:44:48 <alinefm> great! I think we have some points to improve for next sprint: speed up the communication with the community to get all need to do a task
13:44:57 <alinefm> more reviews, more tests
13:46:14 <alinefm> can we move to open discussion or someone want to say anything more about it?
13:47:01 <AdamKingIT> Seems silence is golden
13:47:01 <royce> I think we can move on~
13:47:10 <alinefm> #topic Open discussion
13:47:24 <alinefm> ming, do you want to talk about authorization?
13:49:07 <alinefm> well, anyone has other topic to discuss?
13:50:12 <alinefm> how quite you are today!
13:50:36 <ming> alinefm, I think we should achieve the short goal first, not a full authorization step in 1.2
13:50:39 <alinefm> quiet
13:50:46 <royce> Guys are catching up the deadline:)
13:50:46 <AdamKingIT> still/already sleeping?
13:51:24 <alinefm> ming, agree! the link I posted in the week is just for reference
13:51:44 <ming> alinefm, the short goal is to fix the generic users with privileged and non-privileged users.
13:52:01 <alinefm> for now, my idea is: users with sudo privilege can do everything
13:52:13 <ming> Also, I guess we need to continue to depend on PAM user database in Linux system.
13:52:21 <alinefm> and those users not in this group has restricted access
13:52:30 <ming> Not to create a Kimchi specific user database
13:52:42 <alinefm> ming, yeap
13:52:50 <AdamKingIT> agree, PAM should give us a wide enough capability
13:53:11 <alinefm> ming, when a user logged into kimchi, you will need to check if this user has sudo privilege in the host
13:53:16 <AdamKingIT> for auth, we do want to keep in mind that we'll eventually need to authorize some users to some VMs and not others
13:53:45 <ming> AdmaKingIT, that is great. But that will not happen in 1.2
13:54:17 <AdamKingIT> just want to be sure we keep the goal in mind
13:54:28 <AdamKingIT> might be our 1st 1.3 item :-)
13:55:51 <ming> I plan to mark the API with privileged and non privileged. Obviously, the GET API will not need privilege. DELETE, UPDATE most likely have to.
13:55:54 <rotru> ming; alinefm  just to let you know, I have already created a backend API to add and remove users in the host ... but this is not a kimchi requirement now ... so I am keeping this internally
13:56:37 <ming> rotru, what are those users for?
13:57:02 <rotru> ming;   system users == kimchi users
13:57:33 <ming> rotru, why you need to create your own system users?
13:58:14 <alinefm> rotru, for kimchi we tend to accept the users already available on system
13:58:50 <rotru> alinefm;  ming; yeap, and how will you add new users ?
13:59:24 <alinefm> rotru, it is out of kimchi scope
13:59:42 <pvital_> ming, alinefm: rotru's feature to add/remove users' is a ginger feature
13:59:42 <ming> rotru.  It  is assumed that Kimchi will not add new users and it just to use the existing users in the sytem.
13:59:43 <alinefm> the system admin may do it previously
13:59:47 <rotru> alinefm; thats why I said "keeping internally"
13:59:53 <rotru> alinefm; ginger stuff
14:00:02 <alinefm> rotru, ok
14:01:36 <rotru> ming; your assumption is right ... I just mention that add/remove feature is done because you may think to do it in the future ...
14:01:48 <rotru> you , or someone ...
14:01:57 <alinefm> AdamKingIT, ming, do we have an agreement about what is needed to do for authorization for sprint 2?
14:02:34 <AdamKingIT> i should review what ming posted on the wiki
14:02:44 <AdamKingIT> A little behind in my post holiday reading
14:04:22 <AdamKingIT> we are proposing phase II for Sprint 2, where 'admin role' is anyone w/ sudo priv, and 'user role' is anyone w/out?
14:04:29 <AdamKingIT> https://github.com/kimchi-project/kimchi/wiki/authorization
14:05:10 <alinefm> AdamKingIT, yeap
14:05:28 <ming> AdamKing yes, it should be root probably.
14:06:18 <AdamKingIT> Practically speaking, anyone who can sudo can already manage any of the VMs though virtman, so that makes sense
14:06:27 <AdamKingIT> Unclear how we manage ' The normal user can only view, start and stop the VM assigned to him" but we can discuss.
14:06:50 <AdamKingIT> seems phase II is a good objective
14:08:14 <alinefm> AdamKingIT, we can add a new param for the resources, like 'owner'
14:08:14 <ming> AdamKingIT, just changed the line to " The normal user can only view the VMs, network and storage, while it can not delete or update them"
14:08:30 <alinefm> and the UI can query for this item according to royce patches
14:09:04 <alinefm> ex, /vms?owner='alinefm'
14:09:17 <alinefm> just an idea
14:09:49 <ming> alinefm, I think that is the filter in the UI.
14:10:28 <alinefm> ming, yes - it is for UI
14:10:46 <AdamKingIT> seems like we may need a little more discussion. Not clear we are all on the same page.
14:10:56 <ming> alinefm, finally we need to add a 'owner' for each resource and check the owner in the backend when trying to access the resource.
14:10:58 <AdamKingIT> Would a normal user be able to take actions other than edit?
14:11:07 <alinefm> in backend, in that link I posted on wiki, you can specify a dict {<user>: <uri>}
14:11:52 <alinefm> so cherrypy will block the user when he tries to access an uri not set to him
14:12:07 <AdamKingIT> Role will be a more valuable concept later, though owner may do for now if we can define a path from one to the other
14:13:16 <ming> I think we need to end today's meeting
14:13:22 <AdamKingIT> maybe we can use user group
14:13:30 <AdamKingIT> we are a bit over time
14:13:57 <alinefm> we can continue it after meeting or even in mail list
14:14:02 <ming> Sure
14:14:06 <AdamKingIT> good idea
14:14:34 <alinefm> thanks all for participating! and let's start sprint 2
14:14:39 <alinefm> #endmeeting