13:02:13 #startmeeting 13:02:13 Meeting started Wed Aug 5 13:02:13 2015 UTC. The chair is alinefm. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:02:13 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:02:13 #meetingname scrum 13:02:13 The meeting name has been set to 'scrum' 13:02:47 #info Agenda 1) Status 2) Open discussion 13:02:47 anything else? 13:03:02 nope 13:03:29 nop 13:04:10 #topic Status 13:04:10 #info Please provide your status using the #info command: #info 13:04:31 #info alinefm updated all the upstream branches according to the latest patches sent to ML 13:04:34 #info ziviani sent patches to ML and is working on bugs 13:04:40 #info danielhb reviewed and pushed patches to his personal Kimchi fork. This fork is no longer necessary now that alinefm is back 13:04:53 I also want to thank danielhb for the terrific job when I was out in the last weeks 13:05:10 #info danielhb sent a couple of patches to fix issues with PCI API and memory usage in Power Systems 13:05:19 alinefm, thanks! :) 13:05:31 #info samhenri ported some wok widgets to bootstrap markup and css 13:06:06 #info alinefm is now reviewing all pending patches on ML and will work with lcorreia to make the wok branch more stable 13:06:30 #info harch understanding the UI flow, host tab movement from kimchi to ginger and investigation on authentication module for wok 13:06:36 samhenri, you are working on top of origin/wok branch, right? 13:07:03 well, for now i'm still working with prototypes 13:07:04 herch, do you plan to move the whole host tab to ginger? 13:07:17 samhenri, ok - any patches you can send to ML for review? 13:07:35 samhenri, it'd be better to send small patches to review instead of a large patch set 13:07:47 info WalterNik worked out a proposal for a new function-split between Kimchi and Ginger. 13:07:47 Available for review. Got some feedback via the mailinglist 13:07:53 samhenri, have you checked the bootstrap license? it is compatible with Apache v2? 13:08:12 alinefm, Right now yes, but the final version might vary. We can add/drop things when we move that tab to ginger. Do you have anything specific about this in mind? 13:08:12 #info ramonn waiting response from libvirt team about USB controllers 13:08:18 it is licensed under MIT 13:08:34 #info ramonn reading bugs about 13:08:53 samhenri, good! 13:09:06 #info Abhiram understanding the backend flow of host functionality and move the same to ginger. 13:09:27 #info, Chandra working upon introducing version into REST API of wok branch for Kimchi/Ginger 13:09:56 herch, I had a discussion about that with danielhb (the ginger maintainer) some time ago, and we agreed to move everything from host tab to ginger *except* the host basic info and stats 13:10:11 I can send a patch with some assets that I've been working on but for now I won't include them in the .html pages 13:10:18 as those kind of information may be useful to user balance his/her virtual machines according to host performance 13:10:34 samhenri, sounds good! 13:10:38 #info Jkatta understanding the back end flow of host functionality and move the same to ginger 13:10:48 alinefm, why would you keep host basic info and stats in Kimchi ? 13:10:53 alinefm, so danielhb is already working on it? 13:11:04 samhenri, there are some widgets test files - that load only the widget in a simple HTML - just for test 13:11:04 #info submitted patch for wok base help page, supporting en_US only for now 13:11:29 samhenri, you can update them to use the new bootstrap style - so we can see how it will look like 13:11:36 Aline, all the host information still be part of Ginger and make it as default plugin 13:11:43 herch, at this moment, no. but it is in my short-term TO-DO list 13:12:13 alinefm, we have a usecase where we kimchi will initially not be available but we still want the host basic info and stats 13:12:23 #info pawan REST API versioning for Kimchi plugin Network tab for WOK 13:12:30 danielhb, let me know if you want me to take it up. 13:13:10 understanding the UI flow, host tab movement from kimchi to ginger 13:13:34 danielhb, just want to avoid the duplication. 13:13:47 #info REST API versioning for Kimchi plugin Host tab for WOK 13:13:49 #info pooja REST API versioning for kimchi plugin Storage tab for WOK 13:13:55 WalterNik, herch, chandra, I have an idea to solve that 13:14:07 alinefm, ok... 13:14:07 let's continue on open discussion session 13:14:22 so we can keep focus on one topic per time =) 13:14:23 alinefm i think most of the elements won't show properly if i just edit the html and include the new assets. some of them already have bootstrap classes 13:14:23 herch, feel free to take it the task if you like :) I am not going to look into it until the end of this month 13:14:39 alinefm, do you want to talk about this by opening an issue on github? many projects to that for such kinda things. 13:14:57 herch, at first the features I would migrate is software updates, repositories and debug reports. alinefm is ok with those 3 features going to ginger 13:14:58 herch, I prefer the ML 13:15:23 herch, after that we can discuss moving the other features 13:15:35 alinefm, no problem. ML it is. 13:15:42 alinefm other elements may stop working or showing because bootstrap css overrides a lot of styles 13:16:07 samhenri, I mean the HTML specific for each widget 13:16:12 samhenri, look at - ui/js/widgets/samples/ 13:16:41 samhenri, each sample file only loads one widget in the HTML 13:16:53 so we can see how it looks like without breaking anything on kimchi 13:16:57 alinefm, while danielhb focuses on the software updates, repositories and debug reports, should I take the moving host tab to ginger? 13:16:57 samhenri, makes sense now? 13:17:04 alinefm, let me know what do you think 13:17:23 alinefm, these are the files that i'm editing right now 13:17:28 great! 13:17:48 alinefm i had to change some lines in the js 13:17:59 herch, AFAIU danielhb asked you to start moving software updates, repositories and debug reports to ginger 13:18:10 herch, and then we can discuss more about basic info and stats 13:18:33 alinefm, got ya 13:19:05 Herch, as aline mentioned lets have more debate in the open discussion on this topic ... 13:19:06 alinefm dialog widget for instance, I was going to remove it, since Bootstrap has a modal window widget 13:19:22 chandra, sure. 13:20:12 samhenri, great! just keep us posted in your work - so we can discuss prior you really implement anything 13:20:18 samhenri, just to avoid extra work 13:20:31 alinefm, sure 13:21:11 alinefm one more thing, have you seen my e-mail regarding Helvetica Neue font? 13:21:29 samhenri, I saw on ML but havent read it yet =x 13:21:41 samhenri, I plan to read/reply all the emails on ML by today/tomorrow 13:22:18 alinefm, ok, no problem 13:22:25 samhenri, do we need to import the bootstrap files into kimchi or there are system packages we will depend on? 13:25:56 ok - let's move on to open discussion 13:26:11 #topic Open Discussion 13:26:22 alinefm i'm editing bootstrap sass files so we may need to include gulp, bower and other dependencies like SASS if people want to build just the new UI assets 13:27:03 alinefm, danielhb : iterating on what walternik mentioned "why would you keep host basic info and stats in Kimchi ?" 13:27:04 otherwise we can just add the generated CSS/images/font/svg files 13:27:16 samhenri, ny saying 'build just the new assets' it means it will be a build dependency only? 13:28:26 *by 13:28:59 chandra, those kind of information may be useful to user balance his/her virtual machines according to host performance 13:29:20 alinefm, yes. Suppose we have to fix a css bug/issue, instead of editing the CSS files we would have to edit the SCSS files 13:29:38 for example, the number of cpus and amount of memory on host may impact the amount of memory and cpus on guest 13:30:03 alinefm, I can see that ... but do you expect users to install only Kimchi without any Host Management ? 13:30:08 samhenri, so once built the files we don't need the bootstrap files anymore? 13:30:14 alinefm, If user have Ginger as well he can very well look into that.. 13:30:27 alinefm for now I'm using gulp that is a JS task runner to run libsass and compile SCSS files to CSS 13:30:36 samhenri, I mean, when building the Kimchi package we will include one single file that was built from bootstrap, is that correct? 13:30:43 alinefm correct 13:31:01 WalterNik, yeap! most of our users do that 13:31:25 alinefm, right now true ... but they have the host tab with all the good features 13:32:19 alinefm, if we take out debug reports, code update ... they will miss a lot of functionality without the host plugin 13:32:27 WalterNik, chandra, I also understand that some user running only with Ginger would like the basic info and stats 13:32:39 alinefm, tyes 13:32:46 so it'd propose to move those APIs to wok 13:32:47 alinefm and then if we have to edit or add something new we would have to edit the original files that includes bootstrap original source, our customized version of it and our new widgets 13:33:04 so kimchi and ginger plugins (and any other plugin) can use them 13:33:23 In future it could be containers as well 13:33:35 alinefm, uff ... but from a functionality point of view these are host aspects 13:34:00 agree 13:34:05 alinefm, this would show also on the API uri ... 13:34:36 WalterNik, chandra, I don't want to remove the Host tab from Kimchi as it will be used for the Federation feature as well 13:34:54 in which user will be able to add/remove host peers to do migration and so 13:35:00 so kimchi UI page/ginger UI page both will display host basic info and stats if user installs both? 13:35:30 Abhiram, yes and no 13:36:04 it'd be good to display just in one place when both kimchi/ginger are loaded 13:36:22 for example, and both plugins are loaded we can display the info on kimchi only 13:36:31 alinefm, and from a resource model point of view ... how would that work ? 13:36:33 otherwise, each plugin display the info 13:36:39 I hope this can be imagined if you want to let us say update the "software" for all the peers. Still I am missing the link on being host tab part of Kimchi 13:36:42 WalterNik, the model would be on wok 13:36:51 the base framework for the plugins 13:37:35 chandra, wait - the peers feature is only a link to other servers 13:37:46 chandra, we will not have a single UI covering multiple servers 13:37:53 1 kimchi = 1 server 13:38:34 alinefm, I guess this multihost functionality requires some additional calrification then .... 13:38:35 chandra, so to update the software to all the peers, you will need to access the link to each peer, login and then go to the update 13:38:56 WalterNik, sure! what are the doubts? 13:38:56 ok understood. Also when we talk about the migration then are we only talking about one server ? 13:39:58 chandra, the idea is, select a guest and then select a destination host (that can be a peer or not) and do the migration 13:40:08 by peer I mean other server running kimchi 13:40:11 alinefm, there are some requirements for performing the same actions on multiple servers ... but this is going far beyond our current discussion scope I guess 13:40:32 WalterNik, yeap 13:40:54 WalterNik, we first need to identify which operations would be good to do in multiple servers and why 13:41:05 and then think in a strategy to cover them 13:41:21 maybe other plugin separated from kimchi and ginger? 13:41:26 alinefm, I still don't have a clear picture on your proposal ... would it be possible to have some sketch ? 13:42:11 WalterNik, about the peers or about the basic info + stats? 13:42:35 alinefm, no about your proposal of functionality separation ? 13:42:43 ok 13:43:00 move basic info + stats to wok framework 13:43:21 on Kimchi UI, always load it 13:43:31 on Ginger UI, only loads it if Kimchi is not up 13:43:41 danielhb, agree ^? 13:44:11 Aline this might defeat the purpose of having host plugin separate and again have some functionality part of base ... 13:44:28 which is suppose to be of host information 13:45:10 chandra, the wok framework already provides basic APIs 13:45:20 to login, logout, system config, etc 13:45:39 I don't see host information as too specific to not be part of it 13:45:53 alinefm, I don't see why makes it conditional for kimchi. IMO wok should always show the 'Basic info' tab, doesn't matter which plug-ins are loaded or not 13:46:30 danielhb, hmm... I was not thinking in that way 13:46:45 danielhb, but it seems to be a better approach IMO 13:47:04 danielhb, I thought in only move the API to wok and keep the UI on kimchi/ginger 13:47:21 but let the wok load a "Basic Information" tab is good 13:47:53 alinefm, what I've thought was to actually add a 'basic info' tab in wok. If you run wok standalone, it'll have this tab. I believe the information that is generic enough for any future plug-in 13:48:24 danielhb, yeap - but it breaks the idea to have a plugin framework 13:48:33 as wok would be a 'plugin' in some way 13:48:36 danielhb, why exctly this functionality ? 13:48:46 Right that was the point even I have ... 13:48:59 WalterNik, because it is useful for kimchi and ginger at same time 13:49:40 alinefm, the alternative would be to have yet another plug-in for basic information 13:49:49 danielhb, wouldn't be debug report usefull for both as well ? 13:49:49 alinefm, can be done too 13:50:47 alinefm, danielhb, you see that I have difficulties understanding how you sourt out the functions 13:50:55 i was thinking what if complete ginger can be considered as wok along with current wok we have... it means whenever we install wok it installs ginger something meaningful functionality 13:51:02 danielhb, that's a better approach IMO 13:51:11 WalterNik, yes it should 13:52:10 danielhb, I guess we really need to go trough the functionality and decide where it should go ... 13:52:30 WalterNik, the sort of functions, at least in my head, is 'which features are required for kimchi/ginger' 13:52:44 I even agree, we need some extensive discussion before we conclude some thing on this topic... 13:53:03 danielhb, true ... this is the better formulation 13:53:19 WalterNik, in my opinion, Kimchi is about VMs. Software Update and Repositories are clearly out of Kimchi scope, in my opinion 13:53:32 danielhb, agreed 13:54:00 WalterNik, but then, "memory available" is something that both Kimchi and Ginger uses. This is the kind of feature that we need to decide what to do, because both plug-ins need this info 13:54:08 danielhb, WalterNik, agreed 13:54:49 danielhb, in my oppinion everything which is currently in the host tab + the admin tab features are host scope 13:55:09 WalterNik, as chandra said, we can have an extensive ML discussion (Walter already started one yesterday) about (1) which features matches this profile of 'useful for both' and (2) how to implement/move them to a common 'area' 13:55:17 danielhb, host scope ... not saying that they are not usefull elsewhere 13:55:37 WalterNik I agree, except let us say platform specific functionality 13:55:40 from Ginger 13:57:18 to do not block any progress on that side, I'd say we can start moving software update and repositories to ginger 13:57:19 danielhb, chandra, ok lets try on the ML ... 13:57:25 as we have already agreed about them 13:57:37 alinefm, agree 13:57:52 and we continue on ML about basic info + stats + debug reports 13:58:03 shutdown restart ? 13:58:03 alinefm, danielhb, walternik, agree 13:58:05 sounds a good plan by now? 13:58:14 Abhiram, also move to ginger 13:58:17 alinefm, sounds good 13:58:20 ok 13:58:28 Walter,danielhb,chandra, does read only info can be included in common and any admin actions can go to ginger? 13:59:18 Archana, we are going back again, What do you mean by common ... according to me all these are host functionality 14:00:00 chandra, by common = useful to kimchi and ginger 14:00:08 i suppose archana means wok chandra 14:00:51 chandra, i meant common which needed to both kimchi ginger.. if come to tab name yes host 14:01:02 Right 14:02:01 Abhiram, chandra, WalterNik, danielhb, the ideal solution to that would have a type of plugin that is embedded to an existing tab 14:02:25 so we could create a simple plugin that does not have interface 14:02:33 and other interface loads it 14:02:56 I think eclipse has something similar to it 14:03:09 danielhb, are you eclipse specialist? 14:03:10 =) 14:03:11 alinefm, does seperate basic plugin make more sense to have common stuff, do it will become optional for user to have it or not 14:03:26 Archana, agree 14:03:42 when we start discussing about plugins long time ago, we thought about those 2 types of plugins 14:03:59 those which has UI (tabs and so) and those which can be loaded as part of an existing UI 14:04:09 but we only implemented the first one =P 14:04:19 maybe it is time to resume the discussion on that 14:04:54 alinefm, Archana, we should think about the APIs as well ... I expect exploiters on it 14:05:35 alinefm, Archana, since the plugin may be relfected there 14:05:54 if we think that basic info is any way needed for any plugin, then I think lets not keep this as optional to user by making it plugin. What does rest of team think on this? 14:06:15 yes 14:06:49 WalterNik, agreed 14:06:49 alinefm, I was :P 14:07:31 Archana, "needed by any plugin" is restricted to kimchi and ginger now 14:07:53 but thinking wok as a framework I may want to create a plugin to hold makeup tips =) 14:08:03 so I don't care about host info 14:08:20 alinefm, hmm.. true 14:08:59 Archana, maybe create a plugin that only expose the API without any UI would be good for us 14:09:11 WalterNik, chandra ^ 14:09:16 alinefm, are we really assuming that the framework is such a generic thingy ? 14:09:50 WalterNik, wok is just a web server that loads plugins 14:10:01 plugins can be related to anything 14:10:20 i agree with this 14:10:22 alinefm, I wouldn't put anything directly in the framwork anyhow ... make it rather a default plugin 14:10:31 I guess plugin make sense when it comes to any functionality we want on top of base 14:10:40 WalterNik, me neither 14:10:47 WalterNik, agreed to have default plugin 14:11:18 we are over time now 14:11:28 we can continue on ML 14:11:41 alinefm, but it was worth it :-) 14:12:00 I feel we had some good discussion.. 14:12:06 Thanks everyone.. nice discussion 14:12:23 yeap! I was missing scrum meeting like that =P 14:12:32 :) 14:12:32 Let us continue over ML and then have better conclusion .. 14:12:35 thanks everyone for joining and for the great discussion! 14:12:39 #endmeeting