13:00:28 #startmeeting 13:00:28 Meeting started Wed Aug 21 13:00:28 2013 UTC. The chair is aglitke. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:00:40 #meetingname scrum 13:00:40 The meeting name has been set to 'scrum' 13:00:41 Hi,all 13:00:56 #info Agenda: 13:01:11 #info Roundtable / Open Discussion 13:01:15 others? 13:01:24 I will also add: 13:01:33 #info September Release 13:02:22 arrangement next week? 13:02:41 yep. AdamKingIT will host the scrum next week in my absense 13:03:14 upstream maintain in aglitke's vacation? 13:03:36 There will be no commits to the tree next week, 13:03:46 Why? 13:04:19 It's a good time to dive into those deep features and get the code into great shape. You all can review each other's code on the list without me. 13:04:21 I dont know too 13:04:48 Because I said so :) 13:05:16 I believe that is the best option. 13:05:19 aglitke, then let's define what are those deep features. 13:05:28 But I think the code also need to be merged. Can Adam King take that? 13:05:39 #topic September Release 13:05:54 we can get the code ready to merge this week and work in new code next week 13:05:56 Here are the main things that I want to see upstream for the Sept release 13:06:01 then we will need to review a lot of patches =) 13:06:09 You can reference https://github.com/kimchi-project/kimchi/wiki/Todo 13:06:25 #info ISO Streaming 13:06:36 #info ISO Scanning 13:06:55 #info SSL and Authentication 13:06:58 #info Storage 13:07:08 #info Network 13:07:19 yes, agree 13:07:47 That seems like a big enough list so the extended is all out the window in my opinion,. 13:07:51 #info "cleanup" for lack of a better term 13:08:16 Storage and network don't define specific features. 13:08:36 the mock up of storage is ready 13:08:37 I think we need define what are those specific features for storage and network. 13:08:43 ming: We are looking for a basic storage mgmt ui 13:08:56 zhoumeina: Looked nice by the way :) 13:09:20 zhoumeina has a mockup of the basics for storage 13:09:20 I also want to add: 13:09:26 #info KPI replacement 13:09:28 I think I will send a patch of the feature of storage pools. 13:09:50 I was lumping KPI replacement under cleanup :-) 13:09:57 ok 13:10:31 But agreed, we need that. 13:10:41 ming:I will send you the mockup , so that you can know the feature of that. 13:11:04 what is the iso streaming one? I assume we already have it ,don't we? 13:11:30 zhoumeina: thanks 13:11:31 My goal is to have feature freeze by Sept 15 to allow 2 weeks for testing and bug fixing. 13:11:41 This is going to be our first widely used release. 13:11:45 hopefully. 13:12:38 We will want to start packaging this up for official inclusion into distrros. 13:12:58 royce: alinefm is working on streaming. 13:13:14 aglitke, I'll try to have shallow scan ready in this week before your vacation, may ping you constantly for review in next two days, hope you don't mind:P 13:13:20 aglitke, about iso streaming: the libvirt patch is ready! I will send to the libvirt list after our meeting 13:13:27 It's being able to pass a http://... url in as the cdrom and have qemu streaming the iso on demand. 13:13:32 after that, I will make the changes need in kimchi 13:13:39 as the xml will be a little bit different 13:13:47 royce: Not at all. Whatever it takes to get it merged. 13:14:04 alinefm: any idea on how to support legacy libvirt? 13:14:20 aglitke:I wonder How long of your vocation? one week? 13:14:34 should we use a qemu command line hack if libvirt cannot support your schema? 13:14:46 zhoumeina: It's a 1 week furlough. 13:14:53 not my choice. 13:15:24 aglitke, I will investigate if we can get the iso stream support info easily from qemu/libvirt capacities 13:15:30 then we can decide on that 13:15:38 so it is libvirt support shortage prevent us from using iso streaming, I assume? 13:15:46 maybe we need to disable this option when the qemu does not have this support 13:16:09 alinefm, that need a qemu interface to query that. 13:16:09 royce: Yes, the feature will have to be disabled. 13:16:28 we actually need to query qemu and libvirt. 13:16:50 So we are going to need a flexible mechanism for doing runtime feature checks. 13:17:20 almost like a set of functional tests that run when kimchi starts up. 13:17:48 aglitke, yeap! it will be needed 13:17:59 Ok 13:18:02 I hope qemu can have a capability report interface. 13:18:18 ming: check how libvirt does it. 13:18:43 libvirt has an API getCapacities or something like that 13:18:46 In the beginning we could have a features section in the config file 13:18:50 aglitke: sure. Bothe Qemu and libvit must have. 13:19:10 and streaming could be off by default 13:19:21 and you would have to enable it in the config file. 13:19:47 Eventually we'd want the capabilities tests to be able to select the proper default based on what software is available. 13:19:59 right! and we need to remove the iso stream option from UI when it is disabled 13:20:07 yep. 13:20:20 so we need a capabilities REST API 13:20:28 #info capabilities REST API 13:20:30 I was about to say that 13:20:49 lots of work ahead! 13:20:59 If I am not making a mistake I've already seen some patches related to it 13:21:09 I thought so too 13:21:19 but I haven't reviewed them 13:21:20 I have submitted a /config patch 13:21:30 it shows the server http_port 13:21:41 It can be extended to /config/capabilities 13:22:52 Any other discussion on the Sept release? 13:23:34 About the storage, I think bingbug submitted iSCSI storage support. 13:23:39 the storage usage 13:23:42 https://github.com/kimchi-project/kimchi/issues/12 13:23:49 s/bingbug/bingbu 13:23:56 I have suggested to replace it to disk IO rate 13:24:00 but any comments up to now =) 13:24:45 alinefm: could you resend your post to the list. This time I am sure you will get some better discussion :) 13:25:00 sure! 13:25:10 ming: I don't think iSCSI is on the list of important features for the Sept release. 13:25:27 bing_bu: Please hold onto those patches for later. 13:25:41 aglitke: ok 13:26:05 anything else for September release? 13:26:37 For network support, I think we should support NAT and bridge network at least. 13:26:44 display network traffic? 13:26:49 yuxin still doesn't know who can take the back end of network 13:26:49 anyone working on that? 13:26:50 That won't make it for September. 13:27:02 ming: ^ network configuration 13:27:09 for network, 2 levels of configuration 13:27:10 aglitke: I have finished the code and testcase, so always need rebase 13:27:43 bing_bu: I understand. Best to wait a bit and do one rebase when it is a better time to submit,. 13:27:46 aglitke: ^? 13:27:50 I can take the back end of network 13:28:00 aglitke: ^ means not? 13:28:02 host level: libvert has a default virtual network which is NAT based 13:28:05 :) 13:28:11 ming: Network config is too complex to make it in time for september. 13:28:24 We need to focus on the items outlined above first. 13:28:43 Bridged network need some special configuration 13:28:58 YuXin: Yes and it's highly distro specific. 13:29:12 and error prone. 13:29:23 at guest level, when create a VM, the network need to be selected 13:29:50 we want some network capability that will cover the most basic case for sept, and not be too distro unique 13:29:55 YuXin: we can just use the default network now. 13:30:10 it can be used 13:30:15 aglitke: I think we can add some level support of NAT and bridge network, not necessary a perfect implementaion. 13:30:24 I don't think we have time for any network stuff for sept. I think it is going to be hard enough to get the current list done. 13:30:46 which is infrastructure provided by libvirt, YuXin 13:31:10 http://wiki.libvirt.org/page/Networking#Host_configuration 13:31:21 YuXin: That only works on Fedora 13:31:47 we have networking as part of our base content, and one of the STG projects needs something there. What could we reasonably do? 13:32:16 AdamKingIT: I've thought about it and based on the number of people working on the project -- nothing. 13:32:24 Unless we drop something else. 13:33:19 We have just over 3 weeks until code freeze. 13:34:03 maybe if we step back and look at our project plan, we might find a path 13:34:49 I can think on it and make a suggestion... 1st stop is the things we already have inflight 13:34:51 I am not sure I agree that networking config is higher priority than any of the basic vm operations that we have in plan. 13:35:32 Anyway... We won't solve that here so let's move on. 13:35:34 Did I not mention I am a feature pig? 13:35:41 heh 13:35:59 feature pig? 13:36:05 hehe 13:36:39 aglitke, if we don't support those networking config, the user can not use the VM well on his network. 13:36:42 a joke. Means I always want one more feature 13:37:14 got u, AdamKingIT:D 13:37:14 ming: It works pretty well with NAT right now. 13:37:48 AdamKingIT, user always want one more feature. 13:38:16 I think networking is important but I am being realistic on what I think this team can accomplish in 3 weeks. 13:39:18 so now, when a VM is created in Kimchi, NAT is used by default for network? 13:39:23 #topic Round table / Open DIscussion 13:39:36 YuXin: Yes, however the 'default' network is configured. 13:40:50 #info: UI needs better format 13:41:07 Even for NAT network support, we need allow the user to create his own NAT network besides default one. 13:41:22 And the user can attach the VM to the new network. 13:41:30 eventually, but not in September 13:42:15 I think may be we can talk about network next meeting. 13:42:30 Templates can already specify alternate networks via the rest api 13:42:37 Since it not urgent 13:42:53 We can talk on list about it as much as we like. 13:43:02 That is the most inclusive place. 13:44:02 One last question about network before moving on. Is there any REST API already implemented for network creation? 13:44:12 nope. not yet 13:44:32 AdamKingIT, that's what I talked just now. 13:44:39 Virtual network apis won't be hard. It's basically wrapping the libvirt api 13:45:01 but the UI will be harder 13:45:19 Host networking will be one of the hardest kimchi features to get right. 13:45:30 I want to mention something we discussed last week, to export remote links as net-template, ming's good idea 13:46:11 Meaning if something in network were containable, it would be guest network definition. 13:46:19 k. I think I got it 13:46:20 Can you explain the idea in a bit more detail? 13:46:30 royce: ^ 13:46:41 this is a different topic from networking 13:47:12 Ok, we specify the os_distro and version now uses the remote isolink provided by osinfo.py 13:47:15 aglitke: what does ^ mean？ 13:47:36 ming suggests we make them to be net-template at the startup of kimchi 13:47:40 shaohef: it points to the line above (indicating I was saying it to royce) 13:47:54 so that users can use them directly to create vm 13:48:33 yep. It's a good idea. I am trying to think of how to store them. Maybe the DB is not the best place. 13:49:01 It would be nice if administrators could install their own net-templates onto the system for deployment. 13:49:02 yeah, I saw you proposed the /etc/... 13:49:20 In fact, maybe all templates should be stored this way. 13:49:45 so even when a rest api creates a template, a file gets written to disk in /etc/ 13:49:52 to avoid crash ? 13:50:02 That is what libvirt does for domain xmls 13:50:31 royce, thanks for bring it up. I almost forgot that. 13:51:01 aglitke: seem libvirt has two xml path. static path, and runtime path. 13:51:06 The disadvantage is that file IO might be more error prone and have less performance. 13:51:25 but the advantage is that templates can be "installed" 13:53:19 The UI would have to filter out streaming templates if the iso streaming feature is off though. 13:53:59 the advantage of "install" is? may I ask? since we just store vm config now 13:54:04 would we ever want to see a streaming template if qemu didn't support streamng? 13:54:15 AdamKingIT: No. 13:54:18 it would fail 13:55:09 aglitke, We can classify templates in the backend. 13:55:13 k, so the REST API could/should filter them out, like it might for templates a user isn't authorized to use (pending a resource based authorization model) 13:55:24 royce: Someone could create a distro package that just installs some templates for a given site. For example, IBM could create kimchi-templates.rpm that depends on kimchi. It would only install some templates that are accessible to IBM employees on the intranet. 13:55:37 you just install the package and you have access to those templates in kimchi. 13:56:04 AdamKingIT: True 13:56:15 sounds kinda cool. Something we want to tackle for Sept? 13:56:33 aglitke, that make sense 13:56:54 AdamKingIT: I don;t know. Royce is already looking at it as a part of her local scanning patches. 13:57:48 It means we need to change the model logic for storing templates to writing external .json files instead of using the ObjectStore 13:58:24 could we eliminate the use of the objectstore? 13:58:30 less is always more 13:58:51 We may be able to. Right now we also use it for storing vm metadata. 13:59:06 but we could write files in a similar manner for that too. 13:59:26 royce: Maybe you could just replace the ObjectStore implementation with a file writing backend. 13:59:53 Then the code can continue to use the object store like a db interface but files are read and written behind the scenes. 13:59:58 aglitke, external .json files will be mess if we don't have a right directory arch. 14:00:08 Which would put is in better long term position if we later wanted to support small "clusters" 14:00:08 yep. 14:00:11 OK, that would be in net-template I think 14:00:22 /etc/kimchi/json 14:00:29 under that you have 14:00:39