13:01:47 <aglitke> #startmeeting 13:01:47 <kimchi-bot> Meeting started Wed Oct 9 13:01:47 2013 UTC. The chair is aglitke. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:47 <kimchi-bot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:01:53 <aglitke> #meetingname scrum 13:01:53 <kimchi-bot> The meeting name has been set to 'scrum' 13:02:32 <aglitke> #info Agenda: 1) Testing and release status 2) Set storage pool for a template 3) ISO Streaming 13:02:36 <aglitke> anything else? 13:03:02 <AdamKingIT> 4) welcome back to all 13:03:03 <ming> Looks good to me. 13:03:23 <ming> Look forward to next release. 13:03:32 <royce> Good for me, seems, maybe zhoumeina and shaohe want to discuss exception 13:03:36 <aglitke> AdamKingIT: Yes, I was going to start with that. Hopefully everyone had an enjoyable holiday 13:04:10 <aglitke> #info 4) 1.1 Planning 5) Open Discussion 13:04:18 <aglitke> lots to cover so let's get started. 13:04:29 <aglitke> #topic Testing and release status 13:04:37 <aglitke> #link https://github.com/kimchi-project/kimchi/issues?labels=bug&milestone=1&page=1&state=open 13:04:51 <aglitke> #link https://github.com/kimchi-project/kimchi/wiki/Testing-1.0 13:05:00 <aglitke> We have three release bugs 13:05:27 <aglitke> All have patches and discussions floating on the list now 13:05:34 <ming> https://github.com/kimchi-project/kimchi/issues?labels=bug&milestone=none&page=1&state=open 13:05:41 <ming> How about those floating ones? 13:05:54 <aglitke> They won' 13:06:03 <aglitke> They won't be fixed for this release probably. 13:06:20 <aglitke> For "UI: Some template information are not displayed in pt_BR when creating a VM" 13:06:30 <ming> Maybe we should mark those as mile stone 1.1. 13:06:30 <aglitke> I think we need some UI expertise on this one. 13:06:52 <aglitke> ming: maybe... I periodically review and tag them 13:07:07 <aglitke> zhoumeina / hlwanghl: Do you have any advice? 13:07:29 <aglitke> the current size of the box cannot contain the pt_BR text 13:07:45 <hlwanghl> I'll take a look at it tomorrow 13:07:46 <aglitke> But expanding the size of the normal box makes it seem too big 13:08:05 <hlwanghl> I was working on some patches today 13:08:10 <aglitke> I was thinking we could expand the box on mouse over and click or something 13:08:23 <aglitke> we have to make sure it works for tablets 13:08:32 <ming> Is the box size fixed now? 13:08:35 <aglitke> yes 13:08:57 <alinefm> aglitke, I faced other problem in that template box 13:09:03 <hlwanghl> It's fixed so large text breaks it 13:09:30 <aglitke> yeah. It's a major drawback with fixed size UIs 13:09:30 <AdamKingIT> We want the user to be able to read the 'expected text' in their native lang w/out having to take an explicit action... like mouse over 13:09:47 <alinefm> when the template name is longer than the box width it will be broken in 2 lines BUT the box height is not enough to display the second line 13:10:01 <aglitke> ahh... Yeah, it 13:10:08 <AdamKingIT> if the problem w/ the name, or the translatable text? 13:10:13 <alinefm> so the second line is not displayed in all height 13:10:16 <ming> I think the box should be extensible based on the text length. 13:10:20 <alinefm> the text appears in the middle 13:10:20 <aglitke> it's disappointing that I cannot ever see the whole template name 13:10:49 <alinefm> yes and the second appears in part 13:10:55 <alinefm> *second line 13:11:15 <aglitke> ok... So hlwanghl, anything you can do to help would be great. 13:11:22 <hlwanghl> AdamKingIT , maybe we can make it larger or just replace it with list view 13:11:30 <aglitke> I have assigned it to you hlwanghl 13:11:40 <hlwanghl> Ok 13:11:47 <shaohef> hi all 13:11:54 <hlwanghl> Hi 13:11:58 <AdamKingIT> hlwwanghl: I can chat w. you after. 13:12:03 <hlwanghl> Ok 13:12:27 <aglitke> The rest of the issues don't require much discussion here. 13:12:49 <aglitke> Has anyone encountered issues that they feel should block the 1.0 release? 13:13:10 <aglitke> We need to resolve the translation issues. 13:13:24 <aglitke> I am going to apply the zh_CN patch after the meeting. 13:13:32 <zhoumeina> ok, 13:13:41 <aglitke> then alinefm, you can base your patch on upstream? 13:13:48 <zhoumeina> I found an issue with login window 13:14:05 <zhoumeina> I think it should be fixed before 1.0 release 13:14:08 <aglitke> zhoumeina: I saw your patch 13:14:26 <aglitke> I will review after the meeting. 13:14:41 <hlwanghl> I think she meant other issue 13:14:43 <aglitke> if you want it to block the release, please create an issue for it and let me know the # 13:14:49 <aglitke> oh... 13:14:52 <aglitke> what is that? 13:15:00 <ming> Did you guys have chance to test on leagacy OS lick FC17, RHEL6.2, Ubuntu 12.03 13:15:07 <ming> ? 13:15:12 <aglitke> ming: I have not. 13:15:18 <shaohef> no 13:15:19 <alinefm> aglitke, yes 13:15:21 <aglitke> Only the 4 identified in the matrix 13:15:32 <shaohef> should we support FC17？ 13:15:34 <hlwanghl> Zhoumeina, is it login window height or Seth. Else? 13:15:39 <zhoumeina> the language selector will not chose the right language when init. 13:15:59 <ming> aglitke, 4 indentified in the matrix? 13:16:11 <aglitke> ming: https://github.com/kimchi-project/kimchi/wiki/Testing-1.0 13:16:29 <alinefm> aglitke, did you see the zhoumeina comment about the string in the po file? 13:16:53 <alinefm> will we keep it as it is and change after the release? 13:16:57 <aglitke> Yes I saw it. It's just a message key right? 13:17:15 <alinefm> yes 13:17:22 <aglitke> yeah. Just add the proper translation for the key and don't worry about replacing it with the english phrase now. 13:17:30 <zhoumeina> that is a common issue about how to deal the long message 13:17:49 <shaohef> aglitke: I have give some proposal about this issue 13:17:57 <aglitke> I think for now a key is ok for really long messages. 13:17:57 <shaohef> aglitke: do you agree? 13:18:12 <aglitke> using python AST is too comples. 13:18:14 <aglitke> complex/ 13:18:31 <aglitke> I'd rather us focus on adding features that users will see and love./ 13:18:45 <alinefm> ok 13:18:49 <ming> For, https://github.com/kimchi-project/kimchi/wiki/Testing-1.0, start VM was not tested on RHEL6.4 , ubuntu13.04. And Was it intentional? 13:19:24 <aglitke> ming: I am continuing to rerun tests as part of release prep. A blank means I still need to retest that 13:19:27 <shaohef> aglitke: yes. how about use xgettext instead of python AST 13:19:54 <aglitke> shaohef: because it cannot recognize the native python syntax 13:19:58 <ming> aglitke: Thanks. 13:20:37 <aglitke> ok... let's continue 13:20:40 <aglitke> #topic Set storage pool for a template 13:20:57 <aglitke> This is a feature that missed the freeze date 13:21:33 <aglitke> Since we are getting very close to release I want to withhold it until right after release./ 13:21:46 <shaohef> aglitke: I have try to use cheetach-compile to generate html.tmpl to python code. and then let xgettext scan this python code. 13:21:47 <royce> Did you have chance to see my rebase, aglitke? 13:21:53 <shaohef> aglitke: it is OK 13:22:01 <aglitke> royce: I saw it, but haven't reviewed it yet. 13:22:14 <royce> Today xinding helped to test it 13:22:14 <aglitke> Merging it would be a pretty stark violation of feature freeze. 13:22:26 <AdamKingIT> It would be a big + if we think its stable enough 13:22:52 <aglitke> Honestly I think the only people that will be upset are the PMs. 13:23:13 <aglitke> But the community won't care if it goes out the day after 1.0 13:23:30 <royce> :) 13:23:56 <royce> Sorry for not catching up with this one... 13:24:29 <AdamKingIT> 1000 lashes w/ a wet noodle? (hope that translates ok) 13:24:30 <aglitke> I agree it's an important feature, but life will continue if it goes on next Monday after I cut. 13:24:35 <ming> Is this one [project-kimchi][PATCHv3 0/8] Template storage customization? 13:24:47 <ming> Royce? 13:24:47 <aglitke> ming: Yes, plus one UI patch 13:24:47 <royce> Just because I had two more days vacation:(, right, ming 13:25:08 <AdamKingIT> I wouldn't frown about vacation... 13:25:13 <aglitke> It just hasn't received review beyond AdamKingIT and I 13:25:26 <aglitke> royce: Don't worry too much about it. 13:25:35 <AdamKingIT> Maybe this is the segui to what & when is the next release... 13:25:53 <aglitke> This isn't a proprietary product release. It's Open Source. Things are ready when they are ready. 13:25:56 <AdamKingIT> *segue 13:26:02 <royce> thanks, aglitke 13:26:25 <aglitke> AdamKingIT: yes... 13:26:33 <aglitke> #topic ISO Streaming 13:26:48 <aglitke> We promised a strong start to open development for 1.1 13:27:02 <aglitke> I want to see ISO streaming merged early (next week if possible) 13:27:10 <aglitke> I would love to demo it in Edinburgh 13:27:36 <royce> do you have a meeting there:D 13:27:43 <aglitke> Yes, KVM Forum 13:27:44 <ming> aglitke, but we should have a repository for the latest libvirt update to test the ISO streaming? 13:28:05 <AdamKingIT> I think out early items for next release would be the template/storage pool feature, ISO streaming, networking 13:28:13 <ming> I think we should maintain several repos for the updating packages. 13:28:28 <aglitke> ming: We are going to add the workaround support so you can test with and without the latest libvirt. 13:28:38 <shaohef> AdamKingIT: refactor exception? 13:28:43 <aglitke> What I want to do for iso streaming is enumerate the patch series that are needed. 13:28:54 <aglitke> guys, let's talk about the other items next... 13:28:59 <ming> AdamKingIt, host debug information paused for while. 13:29:08 <shaohef> AdamKingIT: https://github.com/kimchi-project/kimchi/wiki/refactor-exception-%5Brelease-1.1%5D 13:29:24 <AdamKingIT> On refactoring, I think we want to look at a number of items... 13:29:30 <alinefm> aglitke, I've already resumed the work on that 13:29:58 <aglitke> so, streaming patches. 13:30:06 <aglitke> 1) libvirt workaround : aline 13:30:12 <royce> aglitke, for iso streaming, I want this patch merge for it:issue #166: Destroy storage when vm define fails 13:30:19 <aglitke> 2) Distros enumeration: shaohef 13:30:38 <aglitke> royce: ok. We can probably merge that this week 13:30:53 <aglitke> 3) Backend support for streaming? alinefm? 13:30:59 <aglitke> what is needed for 3? 13:31:19 <alinefm> aglitke, with libvirt support the backend is already done 13:31:20 <aglitke> 4) UI enablement: zhoumeina? 13:31:25 <aglitke> ok 13:31:29 <alinefm> just need to added support for libvirt workaround 13:31:34 <ming> 3, qemu support? 13:31:43 <aglitke> ming: it already supports it 13:31:50 <royce> alinefm, are bugs reported previously fixed? 13:31:52 <alinefm> oh and the patch [PATCH 0/3 V3] isoinfo: Probe information from remote ISO file 13:32:07 <ming> aglitke, but it is in the upstream. 13:32:08 <aglitke> alinefm: ok 13:32:23 <alinefm> royce, I am resuming the iso streaming work now 13:32:23 <aglitke> ming: It has supported it for ages. 13:32:29 <alinefm> I will investigate them 13:32:49 <alinefm> and with the libvirt workaround the problems may come out 13:32:51 <ming> aglitke: How about RHEL 6.4? 13:32:57 <aglitke> So if folks could work on getting these patches ready to go for early next week we can have a strong start to our development for 1.1 13:33:11 <aglitke> ming: not sure... You can check. 13:33:16 <royce> I think I ran into different problems when testing on different distros, I'll help you look into them too 13:33:26 <aglitke> ok, gream 13:33:26 <royce> alinefm^ 13:33:28 <aglitke> great 13:33:52 <AdamKingIT> Do we want to cut another release with some of these feature, then tackle some of our structural ideas? YuXin has some thoughts on making more use of jQueryUI, and I have some on using some design patterns in the backend 13:34:05 <aglitke> zhoumeina: how close is the UI for streaming? 13:34:09 <alinefm> royce, thanks 13:34:25 <aglitke> AdamKingIT: We can do all of that concurrently 13:34:34 <aglitke> I agree with all of it. 13:34:44 <aglitke> 1.1 does have a lot of feature development too 13:34:45 <ming> About storage managenment. 13:34:50 <aglitke> It's going to be busy. 13:35:05 <ming> I think we may provide basic snapshots functions for Kimchi in 1.1 13:35:07 <aglitke> I am going to get the list together of things we are committing to work on. 13:35:17 <aglitke> We've already done quite a bit of work in this area. 13:35:32 <aglitke> I'll put up an initial planning page for 1.1 in the next day or two 13:36:13 <zhoumeina> aglitke: I'm sorry, I think the xinding is working at the streaming. 13:36:21 <shaohef> mi 13:36:23 <aglitke> ahh, right... My mistake 13:36:23 <shaohef> ming: https://github.com/kimchi-project/kimchi/wiki/snapshot 13:36:54 <shaohef> aglitke: https://github.com/kimchi-project/kimchi/wiki/snapshot 13:37:11 <ming> shaohef: thanks. 13:37:45 <aglitke> snapshots are complex 13:38:15 <aglitke> AdamKingIT: I will pull the info out of the spreadsheet I've been working with Frank on. 13:38:30 <aglitke> That has a pretty nice list of 1.1 features. 13:38:33 <AdamKingIT> We have quite a bit on the wiki 13:38:35 <AdamKingIT> as well 13:38:44 <aglitke> yep... Lots of work to do 13:38:59 <shaohef> aglitke: a new developer maybe join Kimchi. 13:39:07 <shaohef> aglitke: zhengsheng. :) 13:39:12 <zhoumeina> shaohef: when? 13:39:33 <shaohef> aglitke: he can help on some important feature 13:39:43 <aglitke> Yes, that will be great! Also markwu will be helping on Networking configuration 13:40:33 <shaohef> aglitke: Yes. I have send out a Network patch on backend. and help yuxing on his UI patch. 13:40:44 <shaohef> aglitke: but no one review it. 13:40:46 <aglitke> ok, great 13:40:50 <aglitke> not great 13:41:11 <aglitke> I haven't seen as broad of review activity as I would like. 13:41:20 <aglitke> especially on the more complex patch sets. 13:41:23 <zhoumeina> shaohef: I think you can resend it after 1.0 release, I can help to review 13:41:34 <aglitke> yes, exactly 13:41:38 <shaohef> zhoumeina: yes. 13:41:47 <shaohef> zhoumeina: thank you. 13:41:58 <aglitke> ok... I think we have covered 1.1 planning well enough for today... 13:42:07 <aglitke> #topic Open Discussion 13:42:13 <zhoumeina> exception 13:42:37 <royce> I'll review it iff we are going to accept Network patches 13:42:38 <aglitke> Yes. This will allow us to present localized detailed error reasons to the end user. 13:43:09 <shaohef> aglitke: yes, it is important to USER. 13:43:20 <aglitke> Are there questions about design or implementation? 13:43:33 <zhoumeina> first, we need to define which kind of error should let user know, not all the backend error should be shown to users 13:43:34 <aglitke> I spent some time with shaohef to explain my thinking on it. 13:43:45 <shaohef> aglitke: https://github.com/kimchi-project/kimchi/wiki/refactor-exception-%5Brelease-1.1%5D 13:43:54 <shaohef> aglitke: I file a wiki about it 13:44:12 <shaohef> aglitke: include most of our discussion 13:44:52 <zhoumeina> two kind of error: error caused by user operation. another is for code error. 13:45:11 <aglitke> shaohef: Great wiki page! 13:46:22 <aglitke> For unexpected code errors, we will have a default key that will be 'An unexpected error has occurred' 13:47:06 <aglitke> So basically, if a KimchiError is raised and the reason key is not set, we will use the above default. 13:47:06 <shaohef> aglitke: but zhoumeina does not like this proposal. 13:47:11 <zhoumeina> we use this method implement the exception just like the wiki, but we found that we have to put the map of key and message both in UI and exception .py 13:47:39 <aglitke> That can be solved with a build step. 13:48:10 <aglitke> the keys have to be defined in the backend because the backend needs to know the set of available keys 13:48:16 <zhoumeina> we dont we do the translation at the backend ,aglitke? 13:48:20 <aglitke> but the UI needs to translate them 13:48:43 <aglitke> because how can the backend know the desired language? We are not bleeding the session info into the rest api 13:49:03 <aglitke> The rest api is always english plus a translation key 13:49:42 <aglitke> so we can add a build step to the code that takes keys from exception.py and writes a javascript file in the UI 13:50:44 <aglitke> It's a little bit complex for my taste, but I don't see a way around it. 13:51:38 <ming> aglitke: The key---> UI translate it to messages--->translate it to localized message? 13:51:41 <shaohef> aglitke: do you means a extra script to copy the keys to i18n.html.tmpl? 13:51:46 <AdamKingIT> if the full message catalog is preloaded in the UI, we can be sure we have something to show the user 13:52:23 <zhoumeina> sorry, do I miss something? 13:52:40 <zhoumeina> poor network 13:52:52 <aglitke> shaohef: Yes 13:53:14 <shaohef> aglitke: got it. 13:53:15 <aglitke> So the i18n.html.tmpl will be partially auto-generated. 13:53:34 <shaohef> aglitke: I will add it to the wiki. 13:53:36 <aglitke> maybe we need 2 js files and the ui will combine the two lists at runtime 13:53:51 <AdamKingIT> what would be in the 2 files? 13:53:53 <ming> quite complex. 13:53:53 <aglitke> i18n.html.tmpl is manually created translation strings 13:54:26 <shaohef> aglitke: yes. it is bothersome to write the i18n.html.tmpl manually 13:54:27 <aglitke> errors.html.tmpl is dynamically generated from backend exception.py 13:54:43 <aglitke> then some utility function in the js 13:54:56 <aglitke> function i18ntable() { 13:55:01 <shaohef> aglitke: put it in errors.html.tmpl instead of i18n.html.tmpl 13:55:15 <AdamKingIT> when it comes to JS files, more is usually worse for performance. If we are generating the JS on the server, we can roll in into .min.js at build time 13:55:22 <aglitke> return i18n.html + errors.html; 13:55:23 <aglitke> } 13:55:31 <aglitke> obviously it's bad psuedocode,. 13:55:36 <AdamKingIT> err, no need to combine the messages 13:55:46 <aglitke> AdamKingIT: Yes 13:55:55 <AdamKingIT> but not roll it in w./ the functional js 13:56:03 <aglitke> it can all be rolled in at build timne 13:56:08 <shaohef> aglitke: what is psuedocode? 13:56:29 <aglitke> shaohef: It's code written in plain english 13:56:54 <aglitke> almost code 13:57:00 <zhoumeina> shaohef: you said that backend can do the translation. any method about this? 13:57:15 <shaohef> zhoumeina: yes. backend can do the translation. 13:57:46 <shaohef> aglitke: maybe you should explain why we not let backend do the translation to zhoumeina 13:58:59 <zhoumeina> yes, I want to know that, since the backend can get the language from session, why we don't want to do the translation at the back end? 13:59:00 <aglitke> We are trying to decouple the REST API from user session data 13:59:16 <aglitke> REST APIs are supposed to be session-less by definition. 13:59:22 <aglitke> Each request is independent 13:59:28 <aglitke> and stateless 14:00:06 <aglitke> the REST API is a machine interface. not a human one. 14:00:18 <aglitke> So translation in an API does not make sense. 14:00:44 <aglitke> Translation is the responsibility of the presentation layer (the UI) 14:00:51 <zhoumeina> but if anyone who want to use the rest api, but only can get the key and value, how can he know what happens 14:01:17 <AdamKingIT> We may want the API keys to be numerical, like HTTP response codes 14:01:20 <aglitke> The API will return the key and the expanded message in English 14:01:36 <AdamKingIT> UI can use the #s to choose a msg to display 14:01:41 <aglitke> AdamKingIT: Numerical reason codes are terrible to understand in the code. 14:01:56 <aglitke> so I am suggesting a short string word 14:02:02 <AdamKingIT> constant definitions are awesome for that 14:02:08 <ramonn_> AdamKingIT, alinefm is out because her connection has some trouble 14:02:31 <AdamKingIT> you propose the API return both the code AND an English string? 14:02:32 <zhoumeina> let me think about it. 14:03:11 <aglitke> AdamKingIT: Yes. 14:03:23 <aglitke> it makes it the most useful 14:03:41 <AdamKingIT> hmm, we generally don't like to show preference for a particular language 14:03:53 <aglitke> The keys in the api are already in english 14:04:02 <aglitke> 'name': 'template-1' 14:04:04 <aglitke> etc 14:04:10 <zhoumeina> seems there are no better method than what we do now 14:04:10 <aglitke> The uris are english words 14:04:33 <aglitke> the code is written in english. Python uses english keywords 14:05:01 <zhoumeina> but I still think it would be not a better code. 14:05:51 <aglitke> I am going to end here but will stick around to continue discussing this. 14:05:53 <aglitke> #endmeeting