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