13:00:10 <aglitke> #startmeeting 13:00:10 <kimchi-bot> Meeting started Wed Jul 31 13:00:10 2013 UTC. The chair is aglitke. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:10 <kimchi-bot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:00:17 <aglitke> #meetingname scrum 13:00:17 <kimchi-bot> The meeting name has been set to 'scrum' 13:00:33 <AdamKingIT> Yes. I made the req, I'll fup and get it 13:00:46 <aglitke> Hi everyone :) Thanks for joining the scrum. 13:00:52 <aglitke> #info Agenda 13:01:06 <aglitke> #info Build system and rename changes 13:01:27 <aglitke> #info Planning for the September Release 13:01:44 <aglitke> #info Roundtable / Open Discussion 13:01:49 <aglitke> Anything else? 13:02:05 <zhoumeina> can we talk about what browser we support? 13:02:22 <zhoumeina> and version 13:02:36 <aglitke> sure... added. 13:02:45 <alinefm> more people reviewing patches 13:02:47 <alinefm> ? 13:02:59 <aglitke> alinefm: Yes. I might as well just mention that now. 13:03:25 <aglitke> Right now our model for the most part is that everyone submits patches and I review and apply them when I have time. 13:03:43 <aglitke> There are some exceptions and a few people who are reviewing more code. 13:03:59 <aglitke> What I would like to see is more patch series being reviewed by multiple people. 13:04:14 <aglitke> Especially the more complex series that implement larger features. 13:04:33 <aglitke> It's hard for me to catch everything and review everything. 13:04:51 <sming> aglitke, agree. 13:05:00 <zhoumeina> there is a problem that we UI developers don't understand the backend logic, 13:05:05 <alinefm> as with more people reviewing patches they can come upstream faster 13:05:08 <aglitke> So I will ask everyone to give me a hand with reviews. It will make all of our patches flow into the tree faster. 13:05:12 <zhoumeina> can we do something about it? 13:05:34 <aglitke> zhoumeina: Reviewing patches is one of the best ways to begin to understand new code. 13:05:40 <aglitke> zhoumeina: Start with simple ones. 13:05:50 <aglitke> and you can work to the more complex ones. 13:06:00 <sming> aglitke, do we have a way to honor the people who comments the code but not signed with reviewed-by. 13:06:10 <bing_bu> zhoumeina: I do not think the UI developers should struggling to review the backend code. 13:06:15 <aglitke> I have learned a lot about UI design and code since reviewing lots of patches. 13:06:18 <sming> aglitke, you know give negative comments may take more time. 13:07:17 <aglitke> sming: I am not really going to be tracking it like with ovirt. In general, when I see someone very actively reviewing code I am more likely to focus review on their work. 13:07:31 <aglitke> So that is one way we can all encourage each other to review more. 13:08:01 <aglitke> If someone reviews your patch, try to find one or more of their patches to review in return. 13:08:37 <aglitke> sming: A positive Reviewed-by should take as much time as negative comments because you are making sure the code will work if it is applied. 13:09:21 <aglitke> ok... I think that covers that topic. 13:09:40 <aglitke> #topic Build system and rename changes 13:10:00 <zhoumeina> what about review by pairs, and take turns 13:10:03 <aglitke> Thanks for bearing with the large changes. They are behind us now :) 13:10:22 <aglitke> zhoumeina: If that works for you guys then give it a try. 13:10:23 <zhoumeina> hehe 13:10:45 <aglitke> I have pushed two follow-up patches this morning to resolve issues. 13:11:02 <aglitke> One from me to update the readme. One from shaohef to distribute a missing file. 13:11:47 <aglitke> If anyone else encounters issues feel free to ask here in IRC and we'll find the solution and get the patch merged. 13:11:47 <zhoumeina> I send a patch to update readme 13:12:19 <aglitke> Now that the renames are behind us I will consider some of the other pending patches. 13:12:48 <aglitke> Anything else on this topic? 13:13:13 <aglitke> 1... 13:13:16 <aglitke> 2... 13:13:19 <aglitke> 3... 13:13:21 <aglitke> ok :) 13:13:30 <aglitke> #topic Planning for the September Release 13:13:39 <aglitke> #link https://github.com/kimchi-project/kimchi/wiki/Todo 13:13:55 <aglitke> Everyone, please see the above link. I would like to step through it. 13:14:15 <aglitke> Category: Guests 13:14:23 <aglitke> display storage usage 13:14:59 <aglitke> As per discussions on the mailing list, since the storage stat is not meaningful we are proposing to remove it. 13:15:01 <alinefm> after our discussion in the mail list I sent a patch to remove it from UI 13:15:13 <bing_bu> aglitke: ACK. 13:15:33 <aglitke> bing_bu: Please respond with that in reply to alinefm's patch 13:15:43 <AdamKingIT> The goal of the KPI section of the UI is to give the admin an idea how the VM is behaving 13:15:51 <alinefm> zhoumeina, I could review it as well. It is UI related 13:15:52 <aglitke> I would like to call on others to participate in this as well. 13:16:01 <shaohef> bing_bu is expert on storage 13:16:16 <AdamKingIT> removing rather than replacing will negativly affect the goal as well as the symetry 13:16:26 <zhoumeina> alinefm: OK 13:16:30 <royce> Sorry for late, caught in the rain... 13:16:36 <aglitke> But the current pegged stats are not suitable for a 1.0 release. 13:16:46 <aglitke> nor is a misleading one. 13:16:46 <AdamKingIT> ie I'd rather replace it than cut it off 13:17:12 <aglitke> AdamKingIT: It's easy to carve out the space again for the box when we have something to put there. 13:17:13 <shaohef> royce: the rain is so heavy. 13:17:26 <shaohef> royce: I come home just now. 13:17:31 <AdamKingIT> so we go back to the 1st goal of presenting the admin an idea of how the VM is performing,. Are there other ways we can achieve that goal? 13:17:50 <royce> shaohef, yes, thunder storm 13:17:55 <aglitke> cpu and screenshots are pretty good. 13:17:59 <alinefm> AdamKingIT, thinking... 13:18:21 <aglitke> libvirt provides other stats APIs 13:18:52 <aglitke> But I wonder if that's the right amount of space allocated to this in the UI anyway. 13:19:21 <AdamKingIT> I suspect cutting down to 1 kpi will throw the symmetry off, but we can look at it if there isn't a better way to communicate an overview 13:19:27 <aglitke> We could divide one of those boxes into thirds and present three bars to indicate the same info in much less space. 13:20:02 <bing_bu> I think the space can be filled with icons of disks 13:20:04 <aglitke> Actually, I miss the compact icon display from the dev ui. 13:20:05 <AdamKingIT> The design has a 'list view' that when implemented will minimize screen real estate consumption, for the more text oriented admin 13:20:11 <zhoumeina> can we make some report about that, to give a performance score 13:20:39 <royce> what about provide like network flow instead of disk cosupution? 13:20:51 <aglitke> royce: That is an option 13:21:01 <AdamKingIT> the difficulty w/ scores is that you have to explain the score calculation if its not a standard metric to people 13:21:01 <bing_bu> royce: network flow is too complex 13:21:04 <aglitke> storage bandwidth (like a disk led) 13:21:23 <aglitke> maybe we could have disk and network activity lights 13:21:31 <bing_bu> aglitke: do you mean the disk usage activity? 13:21:40 <aglitke> bing_bu: Yes, IO 13:21:44 <aglitke> not capacitty 13:21:57 <AdamKingIT> Sounds promising. The blinky disk light is one of the best user feedback devices ever (IMO) 13:21:57 <bing_bu> Good option, like LED on laptop 13:22:29 <aglitke> but ours would only refresh every 5 sec so we would use a meter instead of a light 13:22:42 <AdamKingIT> right, we'd want to put a # to it 13:23:00 <aglitke> So maybe for now we should blank the boxes for storage and memory kpi 13:23:01 <AdamKingIT> which could be graphed, or shown numerically in the list view mode 13:23:05 <aglitke> but keep them in place? 13:23:40 <bing_bu> aglitke: AdamKingIT: maybe can be a disk histogram 13:24:07 <AdamKingIT> I would leave them alone until we swap them for something meaningful sometime in the aug iteration 13:24:59 <aglitke> So...I think we should set people off on working this via two angles: 1) blank the current meaningless KPI slots but keep them in the UI 2) Add a 1.0 task for discovering and adding 2 new KPI measures. 13:25:53 <AdamKingIT> by blank, you mean white out that spot in the UI? 13:26:09 <aglitke> Right, no circle with fake number and no title 13:26:15 <aglitke> just the box with background 13:26:26 <aglitke> as if no KPI was selected to occupy that slot yet. 13:26:33 <sming> There? 13:27:01 <AdamKingIT> Selfishly, can we do them in reverse order... Identify the useful KPIs we think we can implement w/out a guest agent, then swap the mocked KPI for the new ones? 13:27:58 <aglitke> OK. I will defer to the UI team on leaving the mocked numbers in place. 13:28:06 <bing_bu> sorry,what is KPI? ") 13:28:09 <bing_bu> :) 13:28:21 <AdamKingIT> np Key Performance Indicators 13:28:34 <shaohef> got it 13:28:38 <royce> I think the IO and network activity make sense, if we add tune in place, we can see the tune result... 13:28:39 <aglitke> Ok. On to Templates section 13:28:56 <aglitke> The main one here is local iso scanning, 13:29:08 <aglitke> I want to briefly share an idea I have on how to do this better. 13:29:16 <aglitke> Royce is already working on it. 13:29:19 <aglitke> for the backend. 13:29:47 <aglitke> The idea is that (at first) we only scan Storage Pools for iso images. 13:30:18 <aglitke> The Storage Volume Resource will be extended to include os_distro and os_version and bootable info for volumes that are iso images. 13:30:51 <aglitke> so the UI can synchronously fetch /storagepools/poolid/storagevolumes 13:31:01 <aglitke> and display a UI of found iso images. 13:31:41 <aglitke> in this mode, the user would highlight the iso images (with distro icons) for the isos to be made into templates and click OK 13:31:59 <aglitke> all of those selected will be added as templates and the process is done. 13:32:12 <aglitke> We still want to have a scan mode. 13:32:16 <aglitke> For this. 13:32:37 <aglitke> The UI can call a new API which creates a temporary Storage Pool 13:32:59 <aglitke> The backend will create symlinks to all found ISOs in the the temp Storage Pool Directoryt. 13:33:29 <bing_bu> aglitke: yeah, I discussed with royce about this, it make sense adding some optional additional information for storagevol if it is a ISO. 13:33:34 <aglitke> When this process completes, (or concurrently) the UI can display the same dialog as above but using the temp storage pool instead. 13:33:34 <royce> aglitke, I tried fedora and RHEL6.3 for slnk today, fedora works fine creating vm with slnk iso, but RHEL6.3 fails 13:33:37 <sming> I was wondering if a installed os image can be scanned as a iso image. 13:34:19 <aglitke> sming: I think we'll just identify iso images by filename extension and then by the isoinfo scanner. 13:34:21 <bing_bu> royce: maybe a issue of libvirt 13:34:31 <aglitke> It's an SELinux issue. 13:34:48 <royce> bing_bu, the same parameter with qemu 13:35:05 <aglitke> I wonder if we can install a selinux policy extension or something. 13:35:08 <royce> aglitke, but I have selinux enforced for fedora too? 13:35:20 <aglitke> royce: The policy is probably different. 13:35:27 <aglitke> less hardened. 13:36:00 <aglitke> Anyway... AdamKingIT zhoumeina what do you guys think about this proposal from a UI perspective? 13:36:10 <royce> I'm not sure, I started with qemu-kvm --cdrom symlink, it works 13:36:35 <aglitke> royce: I think libvirt might be configured to drop permissions. 13:36:37 <royce> but with the parameter formed by our template, qemu fails 13:36:38 <zhoumeina> Ui should show a brief information about each ISO just like cpu memory ,so the user will easily select the one he wants 13:37:03 <sming> aglitke, not sure what is the temp storage pool. When will the pool be removed. 13:37:03 <aglitke> zhoumeina: I was thinking we could show distro and version plus the icon. 13:37:13 <AdamKingIT> I think the approach will work pretty well 13:37:26 <zhoumeina> aglitke: I agree 13:37:35 <AdamKingIT> Seems like we can use it to implement the mockup as is 13:37:49 <aglitke> sming: We can have the UI remove it and maybe also have a timeout when it will be removed. 13:37:52 <sming> aglitke, When will the pool be removed if it is a temp one? 13:38:05 <AdamKingIT> Only issue I can think is how the temp storage pool gets cleaned up 13:38:35 <royce> remove and rescan is time consuming 13:38:58 <aglitke> interesting. 13:38:59 <royce> We can rescan when forced by user 13:39:00 <AdamKingIT> We could/should clean up the temp pool when the user session ends 13:39:13 <aglitke> maybe we can just have a "special" storage pool called kimchi-isos 13:39:22 <bing_bu> why not reserve the temp pool but invisible for user? 13:39:25 <aglitke> that never goes away 13:39:30 <aglitke> a scan just refreshes it. 13:39:44 <bing_bu> yeah, refresh the pool 13:39:45 <aglitke> to refresh, first you remove any links that are broken 13:39:47 <royce> +1 13:39:50 <aglitke> then you scan for new ones. 13:39:51 <AdamKingIT> The nice think about the temp pool is that 2 admins can scan diff areas and get diff results 13:40:04 <AdamKingIT> 2 scans, 2 temp pools 13:40:07 <aglitke> AdamKingIT: true 13:40:17 <aglitke> also you can have concurrent scanning. 13:41:05 <royce> scan diff areas? I assume we don't give user the choice about what directories they will scan 13:41:07 <aglitke> royce: maybe you can implement it in a way that allows us to decide later if we want the temp pool model or the special pool model. 13:41:20 <aglitke> royce: For now, I think we don't 13:41:40 <royce> got u, aglitke 13:41:47 <AdamKingIT> Scan would always scan the whole file system? 13:41:48 <aglitke> There may be two options: 1) scan only local filesystems 2) scan local and network filesystems 13:42:03 <bing_bu> aglitke: I think the feature you mentioned is advanced one :) 13:42:18 <royce> temporarily, yes ,AdamKingIT 13:42:32 <aglitke> AdamKingIT: I can't think of a better way to do it without exposing filesystem heirarchy details to the user. 13:42:49 <aglitke> bing_bu: by net filesystems I mean only those which are currently mounted,. 13:43:00 <bing_bu> royce: no deep scan or shallow scan? 13:43:02 <aglitke> we would not try to discover or mount new ones. 13:43:08 <sming> I think we can look iso images as system resources. And two users scanning process should be serialized . 13:43:10 <bing_bu> aglitke: got it 13:43:24 <AdamKingIT> k, I suggest we design for either, which should be minimal overhead.. and we can decide later... 13:43:33 <aglitke> a shallow scan is the one the UI can do by just looking in existing storage pools 13:43:56 <aglitke> a deep scan is the one that uses the whole fs and a temp storage pool 13:44:02 <AdamKingIT> if scan always scans the whole system, then the special pool will work, If we want to allow diff concurrent scans, then temp pool will be required 13:44:33 <aglitke> the nice thing about a persisting the scan pool is that a future "shallow scan" could look in that pool and benefit from the deep scan. 13:45:00 <aglitke> So royce, I think we need to design with some flexibility in mind. 13:45:15 <aglitke> make it easy to switch between multiple temp pools or a single special pool 13:45:35 <royce> that's reasonable 13:45:56 <zhoumeina> sorry to interrupt, why not share a open folder for iso files? all? 13:46:03 <aglitke> for now I think we start with a special pool that we create in /var/kimchi/kimchi-iso-pool 13:46:22 <aglitke> zhoumeina: Because we cannot move isos around. 13:46:32 <aglitke> we need to leave them where the admin has placed them. 13:47:14 <zhoumeina> aglitke: oh, got it 13:47:15 <aglitke> royce: Also, when you convert an iso from the special pool to the template, the template should use the target of the link, not the special pool for the iso filename. 13:47:28 <aglitke> that way we can delete the special pool without breaking the templates. 13:47:43 <royce> aglitke, yes, of course, some isos with wrong permission also be ignored 13:47:54 <aglitke> ok... We should move on... Looking forward to some patches! 13:48:31 <aglitke> These minutes will be uploaded to the web so we can reference the discussion there. 13:48:57 <aglitke> Is anyone working on authentication? 13:49:16 <zhoumeina> I think not yet 13:49:22 <aglitke> That is a dependency for language selection. 13:49:38 <aglitke> I think we need to start on it if we have any hope of completing it in time for 1.0 13:49:59 <aglitke> AdamKingIT: would you mind leading the charge on this one? 13:51:02 <aglitke> Hmm, no objection! :) 13:51:05 <AdamKingIT> The idea here is that any req to access Kimchi would be met with a forms based authentication chalenge 13:51:35 <AdamKingIT> Authentication would occur through PAM (which I can only spell) 13:51:44 <aglitke> ok. Will that work in the REST API? 13:51:46 <sming> I think authentication have several meanings, authentication to REST APIs. authentication on VM operations 13:51:54 <sming> &etc 13:52:04 <AdamKingIT> Authentication is separate from authorization... 13:52:20 <AdamKingIT> For Sept we are just talking about authentication. Authorization is more complicated... 13:52:34 <aglitke> ACK 13:52:49 <bing_bu> authentication means user/passwd, right? ;-) 13:52:56 <sming> So is is just a login authentication to Kimchi UI? 13:53:00 <AdamKingIT> The idea is that to use Kimchi you would have to authenticate with a uid/pwd known to the linux install, and in the admins group 13:53:02 <aglitke> so any authenticated user (in the admin group) has access to do anything on kimchi 13:53:16 <aglitke> sming: REST and UI 13:53:32 <shaohef> AdamKingIT: we need session for authentication？ 13:53:41 <AdamKingIT> if the linux install is configured to authenticate against LDAP then the uid/pwd would be authenticated against that through PAM 13:53:54 <AdamKingIT> Not necessarily, though you need some token... 13:54:05 <sming> aglitke: Thanks. So we need not to consider libvirt authentication to manage VM now. 13:54:21 <AdamKingIT> My xp here is in the J2EE space, but a similar approach could apply here... 13:54:54 <AdamKingIT> Once authenticated the server issues the user a token (stored in a cookie) which must be presented w/ each request for the duration of the token validity 13:55:16 <aglitke> AdamKingIT: Is that how poster works? 13:55:26 <aglitke> The FF extension? 13:55:33 <AdamKingIT> if the token is expired, or not present, the user is challenged again 13:55:43 <aglitke> I assume the authentication works via a cookie 13:55:44 <AdamKingIT> Not familiar, but I can read up 13:55:52 <aglitke> I can test it out. 13:56:12 <aglitke> Would be cool if you could hack something up and post to the list for us to try. 13:56:14 <alinefm> yeap. I've already implemented it using cookie 13:56:30 <alinefm> when cookie expired the session will finished 13:56:35 <sming> AdamKingIT, how to companion the PAM credentials with REST API calls? How kimchi check those credentials for each REST API? 13:56:39 <aglitke> Once we have this, then we need SSL to avoid sending machine passwords in clear text 13:57:24 <aglitke> AdamKingIT: Wouldn't a REST API user be able to pass credentials as HTTP headers? 13:57:38 <AdamKingIT> The PAM check could be isolated to the authenticate flow, all the other flows look for a valid token 13:57:59 <AdamKingIT> Putting the credentials in the header is basic auth, and generally not considered secure 13:57:59 <aglitke> That's how the BSO challenge works I believe 13:58:14 <aglitke> but if it happens over SSL then it is ok 13:58:52 <AdamKingIT> I am fairly sure that BSO issues you a token 13:59:14 <aglitke> But the first challenge just returns 400 Not authorized 13:59:21 <aglitke> when I use wget 13:59:23 <AdamKingIT> Even over SSL its not considered safe I think because proxies can cache it 13:59:30 <aglitke> hmm 13:59:46 <aglitke> ok... I guess the best thing is for you to send us a prototype to play with 13:59:59 <AdamKingIT> You overestimate my PAM knowledge 14:00:10 <aglitke> I am mostly concerned with the HTTP side 14:00:23 <aglitke> your pam check can just be a 'return True' for now 14:00:52 <aglitke> or 'if user == root and password == passw0rd return true 14:01:01 <aglitke> just to demo the http tech 14:01:08 <aglitke> then we can wire in the pam support next 14:01:15 <AdamKingIT> They'll never crack that one ;-) 14:01:27 <AdamKingIT> Let me look at it and see what I can come up w/ 14:01:40 <aglitke> I just want to see how the authentication scheme behaves with standard tools 14:01:44 <aglitke> cool. 14:02:03 <AdamKingIT> I may need a little advice on the server side, the http bits I am good 14:02:06 <aglitke> Well, that brings us to the end of the meeting. Anyone want to bring up any quick topics? 14:02:25 <zhoumeina> oh 14:02:28 <aglitke> zhoumeina: for browser support. 14:02:35 <zhoumeina> yeah 14:02:39 <aglitke> I think we can add a section in the readme. 14:02:47 <zhoumeina> what kind of , and version 14:02:49 <aglitke> Perhaps it can be: 14:02:57 <aglitke> Supported browsers 14:02:58 <aglitke> ---------------------- 14:03:12 <bing_bu> aglitke: what the RFD V2 new adding iscsi and nfs storage support ?https://groups.google.com/forum/#!topic/project-kimchi/2MUTewMEJzg 14:03:12 <aglitke> The following browsers are tested and known to work well with kimchi 14:03:30 <aglitke> zhoumeina: Then set the list to ones we know about 14:03:37 <AdamKingIT> FF 17ESR +, IE 8(?) +, Chrome (version changes so rapidly its hard to pick), Safari (a little less rapid change) 14:03:38 <aglitke> you can send a patch for this 14:03:52 <AdamKingIT> Do we have any constraints from jQuery? 14:03:57 <aglitke> Just say CHrome 56+ :) 14:04:26 <aglitke> bing_bu: I don't know if that is really high prio for 1.0 14:04:31 <AdamKingIT> The Dojo project I work with is constrained by the Dojo version 14:04:41 <aglitke> AdamKingIT: I am not sure. 14:04:44 <AdamKingIT> not sure if jQuery imposes similar 14:04:46 <aglitke> would be good to check. 14:04:55 <zhoumeina> I will check it 14:05:11 <aglitke> zhoumeina: Perhaps you can just add a conservative list to start with and we can modify it later as more info comes in. 14:05:19 <bing_bu> I think it is easier to add than network, so I do this first.. 14:06:04 <aglitke> bing_bu: I think we are going to want a UI to manage the storage domains first. 14:06:25 <aglitke> bing_bu: let me look at the patches. 14:06:38 <aglitke> If they are backend only and safe, then they may be mergeable. 14:07:01 <aglitke> ok... Want to respect everyone's time. This was a very productive meeting. Thanks for joining everyone! 14:07:05 <aglitke> #endmeeting