13:08:21 <alinefm> #startmeeting
13:08:21 <kimchi-bot> Meeting started Wed Nov 20 13:08:21 2013 UTC.  The chair is alinefm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:08:21 <kimchi-bot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:08:27 <alinefm> #meetingname scrum
13:08:27 <kimchi-bot> The meeting name has been set to 'scrum'
13:08:30 <pvital> royce, I think it's better we go back to scrum
13:08:30 <pvital> :-D
13:08:36 <alinefm> #info  Agenda 1) Sprint 1 2) Sprint 2 3) Open discussion
13:08:42 <alinefm> anything else?
13:08:59 <alinefm> ok
13:09:00 <alinefm> #topic Sprint 1
13:09:02 <ming> looks good
13:09:05 <alinefm> I could merge more patches this week! Thank you all!
13:09:17 <zhoumeina> great
13:09:23 <alinefm> we still need to focus on sprint 1 tasks and sprint 2 as well
13:09:39 <alinefm> https://github.com/kimchi-project/kimchi/wiki/Todo-1.1
13:09:46 <alinefm> from the list, the first item is network
13:10:00 <alinefm> shaohef, I think the interface patches can be merged today
13:10:22 <alinefm> will you work on network patches after that?
13:10:27 <shaohef> alinefm:  sure.
13:10:34 <alinefm> great
13:10:49 <alinefm> about the UI, I made some comments some time ago but I am missing the next version
13:10:51 <alinefm> any update?
13:10:54 <shaohef> alinefm:  as we discuss today, both network and network IO depends on it.
13:11:02 <YuXin> if backend network patch got merged, I can get frontend patch V2 sent out quickly
13:11:09 <alinefm> shaohef, depends on interface patches?
13:11:16 <shaohef> alinefm: yes.
13:11:17 <alinefm> YuXin, great!
13:11:36 <alinefm> shaohef, YuXin, anything else do you want to address related to network patches?
13:11:51 <shaohef> alinefm:   I will on line this evening. any problem about interface let me know.
13:12:05 <YuXin> shaohef, please rebase your other backend patches and then Aline can review it
13:12:24 <alinefm> shaohef, ok
13:12:38 <alinefm> next: Basic host management (host)
13:12:52 <alinefm> now I am seeing more progress in it
13:13:09 <alinefm> shaohef, I think the static data patches are ready too
13:13:27 <alinefm> you need to work out on disk io and network io patches now
13:13:47 <alinefm> do you think we can merge them still this week?
13:13:54 <shaohef> alinefm:  that's great. I will starting on them.
13:13:58 <shaohef> alinefm: thank you.
13:14:29 <alinefm> hlwanghl, the UI also looks good
13:14:36 <hlwanghl> I think we are close to finish it.
13:14:38 <alinefm> I made some comments yesterday
13:14:44 <hlwanghl> Thanks :-)
13:14:54 <hlwanghl> Yeah I see
13:15:10 <alinefm> markwu suggested to remove (instead of disable) the debug reports when no report tool is available
13:15:18 <alinefm> any comments? suggestion? concerns about that?
13:15:24 <alinefm> ming, markwu ^
13:15:32 <shaohef> YuXin: yes. rebase is always tedious. You do not suffer it
13:15:49 <hlwanghl> I suggest disable
13:15:50 <AdamKingIT> We generally don't remove UI elements like that
13:15:52 <markwu> alinefm, nope,  I didn't suggest that
13:16:15 <royce> shaohef, interface patch are independant I think, it'll be quick
13:16:18 <markwu> I suggest we need have a explicit requirement of the report tool
13:16:39 <pvital> alinefm, markwu, AdamKingIT: IMO disable is better than remove something from the interface
13:16:58 <shaohef> royce:  thanks for you review.
13:16:59 <markwu> again,  I didn't suggest remove anything
13:16:59 <pvital> user can see that the fuction is there, but not availbale
13:16:59 <AdamKingIT> pvital: yes.
13:17:06 <ming> alinefm,. not sure what is remove?
13:17:13 <alinefm> markwu, sorry! maybe I misunderstood you
13:17:20 <AdamKingIT> markwu: what did you suggest removing again?  ;-)
13:17:22 <shaohef> pvital:  agree.
13:17:25 <royce> shaohef, yw, just feedback for your review to me:)
13:17:25 <pvital> markwu, sorry!
13:17:46 <ming> I think mark's idea is about how to check the tools instead of removing it.
13:18:14 <alinefm> markwu, for rhel, fedora, I am OK in adding sos dependency
13:18:23 <ming> Checking the tool with packages can work sometimes.
13:18:25 <markwu> np,  my point is that we need make sure the tool is available to expose the feature implemented in kimchi to user
13:18:26 <alinefm> but we do not have a specific tool for ubuntu and opensuse
13:19:00 <ming> alinefm, that is to be done.
13:19:05 <markwu> alinefm, is supportconfig  for suse?
13:19:17 <ming> markwu, it is listed there.
13:19:23 <ming> But need more work
13:19:35 <markwu> sos is also available for ubuntu, but only for the latest version
13:19:38 <ming> not hard, but need more test.
13:20:12 <ming> so the basic ideas is to test the command directly instead of checking the static packages.
13:20:33 <ming> User do have chance to install the tools in non-package way.
13:21:21 <markwu> alinefm, if it's really not available on ubuntu,  I think we need your patch,  but I hope it also can expose the tool it can use
13:21:47 <alinefm> markwu, and expose the tool name on UI?
13:21:48 <ming> markwu, why should the user know that?
13:22:03 <ming> The tools should be hiden from the user.
13:22:36 <markwu> ming, if the user don't what the report is,  he can't get better understand of the content
13:22:43 <ming> The idea is if the system get two, we chose one by priority.
13:23:18 <ming> markwu, the user need to download the log files, he should be expert on the content of the log file.
13:23:26 <shaohef> ping
13:23:55 <AdamKingIT> shaohef: pong
13:24:07 <hlwanghl> Haha
13:24:18 <shaohef> AdamKingIT: I'm  living :)
13:24:27 <markwu> we should not assume that. for me,  I am familiar with sos,  but I have no idea about other tool
13:24:30 <AdamKingIT> shaohef: hooray!
13:24:48 <alinefm> markwu, it can become complex while handling multiple report tools
13:24:56 <AdamKingIT> I agree we want some abstraction in the UI from the backend debug tools,,
13:25:00 <ming> makrwu, Kimchi only provide a way for the user to download the log file.
13:25:05 <alinefm> one report can be generated using a tool-A and a second one using tool-B
13:25:17 <markwu> if it's generated by other tools,  probably I need know it's generated by which tool,  I can do a research on tool to know what log files it contains
13:25:20 <ming> the log file can be in different format.
13:25:45 <markwu> alinefm, for me,  I don't think we need support multiple tools for one platform
13:25:47 <AdamKingIT> If there is more than one choice, we can run them all and combine the results, or make it admin configurable which tool is to be used
13:26:52 <ming> AdamKingIT, I think that expose too much details to the user.
13:27:02 <alinefm> markwu, agree
13:27:06 <ming> Kimchi can chose one for them.
13:27:08 <markwu> AdamKingIT, I think we could just choose the most popular tool for that platform
13:27:12 <pvital> I think the second option of AdamKingIT is good
13:27:18 <markwu> for fedora and rhel,  sos is enough!
13:27:47 <AdamKingIT> if there is an obvious choice we should take it.. I am not thinking that the admin would have a choice via the UI, more like a backend config file
13:28:44 <AdamKingIT> but by all means, if one tools is the standard for a platform we should use it
13:28:50 <alinefm> markwu, I think we could make it dependent of platform and document which tool is using for each one
13:28:52 <royce> markwu, is power linux also use this?
13:28:56 <alinefm> and do not expose anything on UI
13:29:18 <markwu> alinefm, I am find with it
13:29:25 <markwu> s/find/fine/
13:29:38 <alinefm> ming, do you also agree? ^
13:29:39 <AdamKingIT> we definitely want to keep the UI simple. Our target user likely doesn't have an opinion which tool to use
13:29:55 <markwu> royce, sos is arch agnostic, written in python
13:30:15 <ming> alinefm, do you propose a static mapping?
13:30:57 <alinefm> ming, yes! we identify the os on host and map it for a tool
13:31:03 <alinefm> fedora/rhel => sos
13:31:09 <pvital> royce, markwu: just checked that thereis the sosreport on fedora19 in ppc64
13:31:25 <royce> thanks, pvital, markwu
13:31:35 <ming> alinefm, that is not the way. Ubuntu and Suse can also have sosreport on it.
13:31:48 <alinefm> ming, but which is the default tool?
13:31:51 <markwu> pvital, thanks for confirmation
13:32:09 <alinefm> the idea is always uses the default tool for each platform
13:32:11 <ming> alinefm, now I list three tools.
13:32:25 <ming> try the tree tools one by one.
13:32:40 <ming> sosreport is the most preferred on
13:33:44 <pvital> ming, could not find sosreport on debian - using only official apt repositories
13:34:05 <YuXin> if I understand correctly, the report is generated by a tool and must be interpreted by that tool also, right?
13:34:11 <alinefm> using default tool we can easier find a package dependency for kimchi
13:34:29 <ming> sosreport, supportconfig,linuxexporlers...
13:34:38 <ming> the list is extensible.
13:34:47 <markwu> pvital, https://github.com/sosreport/sosreport
13:35:10 * pvital is checking the link
13:35:14 <ming> pvital, if a new tool was found, the tool should be added into the list.
13:35:21 <ming> s/was/is
13:35:39 <alinefm> ming, that way one report can be generated using a tool-A and other using tool-B
13:35:49 <alinefm> it will get the user confused
13:36:08 <pvital> hum!!! on debian it's in the sid repository!
13:36:20 <pvital> I'm running the stable one
13:36:23 <ming> alinefm, why? only one tool will be determined.
13:36:39 <alinefm> ming, nope
13:36:57 <alinefm> think I have installed supportconfig and generate a report from kimchi
13:37:04 <alinefm> then I install sos package
13:37:11 <alinefm> then kimchi will use sos to generate the report
13:37:15 <alinefm> let's move forward - we have more items to discuss
13:37:20 <alinefm> we can continue after meeting
13:37:27 <shaohef> pvital: so a request in the spec file ?
13:38:01 <alinefm> next: Add extension interface for Advanced host config (host)
13:38:09 <alinefm> markwu, zhoumeina ^
13:38:28 <zhoumeina> yes
13:38:35 <alinefm> markwu, I am missing the next patch series about the backend
13:39:16 <alinefm> also I would like to expose my thoughts about the plugin structure
13:39:26 <zhoumeina> ok
13:39:40 <alinefm> /plugins/<plugin-name>/*.py (backend files)
13:40:03 <alinefm> /plugins/<plugin-name>/ui/<css, js,...> (ui files)
13:40:25 <alinefm> /plugins/config/ui/<plugin-name>.xml (tabs.xml files for each plugin)
13:41:18 <alinefm> we need to make sure to do not expose the backend files
13:41:22 <alinefm> zhoumeina, ^
13:41:43 <alinefm> for that I suggested put all config file in a same dir
13:42:08 <markwu> alinefm, I update it on my local repo, and working on the test case.  but I am not very keen on the plugin support.
13:42:09 <alinefm> the plugin owner will be responsible to expose what else he/she wants
13:42:25 <AdamKingIT> alinefm: You mean prevent a user from accessing the xml file?
13:42:28 <zhoumeina> alinefm: The plugin files whatever front-end and backend are all developed by 3rd party people
13:42:35 <ming> Is it necessary to expose /plugins/<plugin-name>/*.py ?
13:42:48 <zhoumeina> Why can not expose it ?
13:43:04 <alinefm> zhoumeina, because it is the backend - we should no expose it
13:43:17 <markwu> alinefm, at least it's not very attractive for kimchi-ginger
13:43:19 <alinefm> the plugin owner should be able to decide what he/she wants to expose
13:43:28 <AdamKingIT> Good security practice would say the end user shouldn't be able to GET anything that they don't need. Seems to be the .py files have the same issue
13:43:44 <ming> Also, an example, if we need add a power specific host data, how can we add that data?
13:44:21 <alinefm> markwu, but it must be done for sprint 1
13:44:29 <ming> The same issue for the template.
13:44:33 <AdamKingIT> while we are on the subject of plugins, we need to consider how plugins can provide help
13:44:59 <alinefm> markwu, if you do not want to work on that anymore we can reassign the task
13:45:20 <markwu> alinefm, I can continue to work on it.  but we should also consider the background of that task
13:45:47 <markwu> we have a lot of core functions to support for kimchi,  why do we eager to support plugin
13:46:01 <markwu> that's the requirement of kimchi-ginger
13:46:01 <zhoumeina> yes, we don't know the background very clear.
13:46:06 <ming> I still can not understand what is plugin's meaning.
13:46:21 <AdamKingIT> plugin is the means for ginger to extend kimchi
13:46:49 <markwu> but it turns out that not all ginger patch could be done in a plugin way
13:46:51 <markwu> . For example, we would like to expose some power specific information by the uri /host/config. Obviously it's not suitable for kimchi base, and it does't worth a separate app plugin because of the minor difference and a new api for will make things confusing.
13:47:01 <zhoumeina> it is for ginger to extend kimchi, right?
13:47:28 <AdamKingIT> zhoumeina: yes
13:47:33 <alinefm> markwu, I suggested another approach for this case
13:47:49 <AdamKingIT> markwu: we probably need to talk more about that use case...
13:48:05 <alinefm> markwu, this second approach work with listeners and registers (like "Eclipse") - that way a plugin can add content to an existent tab.
13:48:13 <shaohef> can we split model.py?  model.py can benefit from it
13:48:20 <zhoumeina> so both backend and frontend files in one folder, tab.xml for this plugin in another folder?
13:48:29 <AdamKingIT> we have an item for s2 to refactor some of the code
13:48:38 <shaohef> will we split model.py by plugin?
13:48:50 <markwu> alinefm, do you want add a lot of listener or hook point in kimchi base's code?
13:49:01 <AdamKingIT> I will propose we split it by resuorce
13:49:08 <ming> About it seems it is pretty difficult for us to add some power specific data to a existing Kimchi base structure in totally seperate  way.
13:49:21 <zhoumeina> alinefm: I have another item not very clear
13:49:46 <markwu> AdamKingIT, even for the same resource,  it could have different attribute on x86 and power platform
13:49:53 <zhoumeina> why we have to make <plugin-name>.xml?
13:49:58 <zhoumeina> why not make one xml?
13:50:03 <alinefm> markwu, I  only have an idea about it - how it will be implemented need to be discussed
13:50:08 <alinefm> zhoumeina, which one?
13:50:12 <ming> markwu, that is a big issue.
13:50:13 <markwu> so that's not feasible to totally split by resource
13:50:31 <AdamKingIT> zhoumeina: I would suggest a standard name w/ the plugin...
13:50:44 <alinefm> zhoumeina, each plugin will install its own file
13:50:51 <AdamKingIT> similar to how every J2EE app has a web.xml withing
13:50:53 <alinefm> during the package installation we can not edit a file
13:50:59 <ming> markwu, so you use hook registered to the resource?
13:51:00 <alinefm> you just add files to the system
13:51:01 <zhoumeina> how to install a plugin?
13:51:11 <AdamKingIT> s/withing/within
13:51:15 <markwu> alinefm, I just have a concern about the overlap kimchi and kimchi-ginger can't be resolved by a clean plugin way
13:51:26 <zhoumeina> user have to add plugin folders and another xml, right?
13:51:31 <markwu> ming, that's not my proposal
13:51:51 <AdamKingIT> I would suggest that all of the contents of the plugin be contained w/in the plugin folder
13:51:55 <alinefm> zhoumeina, it will be a package
13:52:01 <alinefm> rpm or deb one
13:52:03 <AdamKingIT> with some areas "pubic" and some private
13:52:29 <zhoumeina> alinefm: I mean the xml
13:52:37 <zhoumeina> xml in another folder
13:52:37 <alinefm> AdamKingIT, that way we need to get the plugin owner expose or not the tabs.xml file
13:52:43 <markwu> currently,  I think we could make the repo of kimchi-ginger include all code kimchi base and ginger piece. all melt together
13:53:07 <ming> markwu, maybe another repository.
13:53:14 <ming> with duplicate code.
13:53:19 <alinefm> AdamKingIT, zhoumeina, which can be a good deal!
13:53:38 <markwu> ming, yes
13:53:50 <AdamKingIT> eeps, fork the code?
13:54:01 <alinefm> we do not need to care about what files the plugin expose and let the plugin does it
13:54:31 <alinefm> the kimchi only can assume tabs.xml will be available and try to get it
13:54:31 <YuXin> I still have question about the purpose of this feature, whether we want to design a framework to get kimchi features more structured or create run-time plugin like eclipse/browser plugin.
13:54:50 <alinefm> YuXin, run-time plugin like eclipse-browser
13:55:42 <YuXin> what is the requriment of this feature, real customer requirement or something we have figured out totally in mind
13:56:09 <AdamKingIT> alinefm: it could be the headache (literal not code) but I didn't follow the good deal
13:56:49 <alinefm> AdamKingIT, so we need to put all config files together and expose this dir
13:57:12 <zhoumeina> let we think about how we can develop a pulgin , we have to make a package , let us call it pulginA, and we have to put it into kimchi, then I have to make a pluginA.xml.
13:57:15 <AdamKingIT> Together as in not contained w/in the plugin?
13:57:45 <zhoumeina> alinefm: right?
13:57:51 <alinefm> AdamKingIT, together = same dir
13:57:51 <AdamKingIT> YuXin: Ginger team has need to add certain host management functions beyond what would be expected of a KVM mgmt tool. The plugin item is a means to accomplish that
13:57:59 <alinefm> AdamKingIT, /plugins/config/ui/<plugin-name>.xml (tabs.xml files for each plugin)
13:58:08 <alinefm> zhoumeina, right
13:58:27 <zhoumeina> Another problem come
13:58:41 <AdamKingIT> Hmm, I think I disagree atm. Keeping a plugin self contained has some obvious benefits that I don't see balanced by splitting it out
13:58:53 <zhoumeina> if we have 3 xml. How can decide which tabs load first?
13:59:38 <alinefm> zhoumeina, the old installed first
13:59:51 <alinefm> we can check the file date/time
14:00:13 <alinefm> AdamKingIT, we have 2 ways to solve the problem and you do not agree on anyone =s
14:00:58 <AdamKingIT> I think there are 3 solutions on the table, one of which I prefer
14:01:03 <shaohef> configure file determine which load first?
14:01:09 <AdamKingIT> Any of the 3 will work
14:01:53 <zhoumeina> I agree put them in configure files
14:02:03 <AdamKingIT> Though all 3 solve a higher level problem. None of them gets at markwu's discussion point, which I assume we'll take up on the list
14:02:17 <pvital> shaohef, zhoumeina +1
14:03:00 <alinefm> shaohef, zhoumeina, which config file?
14:03:29 <AdamKingIT> I can try to write what I see as the plugin use case requirements, and the 3 solns offered to the list
14:03:39 <zhoumeina> you said that ui-config.conf
14:03:40 <shaohef> now we just one config.py
14:03:53 <shaohef> we can add a new configure file
14:03:54 <alinefm> shaohef, and how a plugin installation will edit it?
14:04:22 <alinefm> AdamKingIT, we can also load the tabs.xml for each plugin dynamically
14:04:24 <zhoumeina> but I think it is a little difficult for 3rd developers
14:04:43 <markwu> AdamKingIT, yes, we could discuss in mail, but I don't like to put it kimchi's list because it's out of kimchi's scope
14:04:45 <zhoumeina> because he has to change two place when add a plugin
14:05:02 <alinefm> AdamKingIT, put all data into /plugins/<plugin-name> and before server startup get the tabs.xml from each plugin and expose just it
14:05:04 <alinefm> zhoumeina, ^
14:05:25 <shaohef> alinefm:  oh, we need a plugin. does that means different plugins has different loader order?
14:05:58 <pvital> markwu, AdamKingIT: agreed!
14:06:17 <AdamKingIT> markwu: I would say the extension interface is in kimchi's scope, if not the details of what the extension contains, much like this plugin discussion
14:06:17 <alinefm> shaohef, we can assume all plugin will be appended to kimchi tabs
14:06:50 <ming> I think evil is in the detail.
14:07:00 <ming> markwu, can you give the detail later?
14:07:08 <AdamKingIT> alinefm: thats along the line  I was thinking
14:07:17 <markwu> AdamKingIT, the biggest motivation to support extension interface in kimchi is for kimchi-ginger
14:07:58 <alinefm> our time is over!
14:08:02 <AdamKingIT> markwu: correct. ginger is the genesis of the requrement
14:08:25 <alinefm> we can continue discussing after meeting
14:08:42 <alinefm> pradeep, do you have anything to share about nfs pool?
14:08:42 <markwu> my point is plugin is not suitable for ginger.  so that's not suitable for kimchi upstream list
14:09:04 <alinefm> danielhb, pvital, ahything from sprint 2 tasks?
14:09:05 <pradeep> alinefm: 1) I need to rebase to latest and send.
14:09:05 <pradeep> 2) need to fix invalid ip, nfs mount ( that will be resolved once royce send his patch to list nfs mount points)
14:09:05 <pradeep> 3) Waiting widget ( will be added as improvement later)
14:09:05 <pradeep> Is there any thing: i need to add
14:09:12 <zhoumeina> alinefm: can we put all the files in one folder, and only expose xml?
14:09:16 <shaohef> markwu: what's the best way for kimchi-ginger?
14:09:18 <pradeep> shaohef: royce: ^^
14:09:46 <royce> alinefm, we found cherrypy got blcked when handing request
14:09:47 <zhoumeina> alinefm: ??
14:09:57 <alinefm> zhoumeina, yes
14:10:04 <royce> I think if cherrypy won't block
14:10:12 <markwu> shaohef, we could talk on email
14:10:17 <pvital> alinefm, not from my side yet! I'm going to send the yum patch in the beggining of next week
14:10:24 <alinefm> rotru, pradeep, why it blocks?
14:10:24 <shaohef> markwu:  Ok.
14:10:28 <AdamKingIT> Seems plugin design trajectory addresses one ginger need, but not another
14:10:28 <alinefm> royce, ^
14:10:33 <zhoumeina> alinefm: or maybe expose xml and front-end files
14:10:37 <royce> even nfs mount blocks we can tolerate
14:10:43 <alinefm> zhoumeina, only xml
14:10:43 <shaohef> alinefm:  yes. royce do some test. a thread in mail-list
14:10:47 <zhoumeina> it is better ,right?
14:11:13 <zhoumeina> html and css also have to expose
14:11:15 <danielhb> alinefm, reworking on the backend of Storage Pool based on local disk, as markwu requested
14:11:21 <zhoumeina> or the tabs will not work
14:11:26 <alinefm> zhoumeina, we (kimchi) will only expose the xml
14:11:38 <ming> Storage: New Storage Pool based on local disk (storage)
14:11:40 <ming> (danielhb) Discover unused local disks
14:11:41 <ming> (danielhb) REST API to represent available local storage
14:11:49 <zhoumeina> ok
14:11:57 <ming> I think Rocye already covers the storage APIs.
14:12:01 <royce> alinefm, see my investigation in shaohef's mail thread, markwu will  investigate this
14:12:24 <pradeep> alinefm: Libvirt storage subsystem issue
14:12:46 <pradeep> alinefm:  so nfs mount taking 120 secs
14:12:49 <royce> ming, what I cover is nfs and logical discovery, local disk we need to use danielhb's
14:12:50 <alinefm> royce, I have understood it only takes a long time to mount
14:12:52 <zhoumeina> alinefm: why not expose html?
14:13:23 <danielhb> royce, "logical" you mean like partitions?
14:13:24 <royce> alinefm, it takes long time to mount, but since cherrypy is multithread server
14:13:35 <royce> it should handle other requests
14:13:40 <shaohef> logical == lvm?
14:13:45 <ming> danielhn "logical" is lvm.
14:13:50 <alinefm> royce, got it
14:13:51 <royce> but in infact it blocks when one request block
14:14:09 <royce> danielhb, logical  is lvm pv
14:14:16 <danielhb> royce, I see
14:14:25 <alinefm> #endmeeting