13:01:02 <aglitke> #startmeeting
13:01:02 <kimchi-bot> Meeting started Wed Sep 18 13:01:02 2013 UTC.  The chair is aglitke. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:02 <kimchi-bot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:01:08 <aglitke> #meetingname scrum
13:01:08 <kimchi-bot> The meeting name has been set to 'scrum'
13:01:12 <ming> aglitke, we will come back to work on Sunday.
13:01:28 <aglitke> #info Agenda: 1) Remaining items for next release
13:01:34 <aglitke> that's all I have.
13:01:41 <aglitke> I want to do a quick review of what remains.
13:02:01 <aglitke> anything else?
13:02:29 <aglitke> #topic 1.0 outstanding patches
13:02:30 <ming> looks good to me, I think we have accomplished all the feature lists in this reales.
13:02:36 <aglitke> Here is my list
13:02:44 <aglitke> (Aline) KPIs -- Awaiting next set of patches
13:02:44 <aglitke> (XD) Streamline template creation flows
13:02:44 <aglitke> Are you working on this?  When might we have patches to look at?
13:02:44 <aglitke> (XD) Allow a user editing a template to specify a custom storage pool
13:02:44 <aglitke> (HLW) Update UI to make use of enriched responses
13:02:45 <aglitke> (HLW) Add languange selector to login screen, set in session, update i18 to be sensitive to session setting
13:02:45 <aglitke> (Bing Bu) REST API to manage storage pools
13:02:57 <aglitke> alinefm: I await your next patch series for KPI
13:03:21 <alinefm> aglitke, yeap! I will send them out after this meeting
13:03:30 <aglitke> I see XinDing is not on today
13:03:39 <aglitke> nor hlw
13:03:42 <zhoumeina> he is on vocation
13:04:19 <royce> bing bu's storagepool refresh patch depend on apporc's autostart patch, if the "REST API for storage pool" are referring to this.
13:04:24 <aglitke> zhoumeina: Can you answer for them?  Do you know if xinding is working on the UI flow redesign and adding the storage pool selector to the template edit page?
13:05:00 <aglitke> royce: ok.  Maybe someone can line those patches up together in one series.
13:05:12 <zhoumeina> aglitke: I think not yet
13:05:21 <aglitke> I know bing bu has moved on so hopefully someone can pick them up.
13:05:27 <royce> I have rebased it, can be sent after the auto start's merged
13:05:51 <royce> I can take them if we all agree :P
13:05:52 <aglitke> zhoumeina: ok... We need to have it completed for the release.  Hopefully it can be started soon.
13:05:52 <shaohef> royce: I will call apporc
13:06:00 <aglitke> royce: Fine for me
13:06:15 <aglitke> it's not urgent and can wait until next week,.
13:06:27 <aglitke> Next week is our last week for new feature development.
13:06:28 <royce> aglitke, so when are they due?
13:06:35 <ming> zhoumeina: Can you reiterate the issues for REST API to manage storage pools. ?
13:06:47 <royce> shaohef, that's really nice of you
13:06:53 <zhoumeina> aglitke: I will tell him about the UI redesign of template soon.
13:07:02 <aglitke> zhoumeina: ok, thanks.
13:07:27 <aglitke> Finally, we have the language selector at login.  Hope to see it next week.
13:07:37 <ming> default storage pool fix is not in yet?
13:07:56 <royce> right, ming, but I think it is ready
13:07:57 <aglitke> ming: adding one when missing?
13:08:10 <ming> aglitke: yes.
13:08:10 <aglitke> has it been recently sent?
13:08:20 <shaohef> ming:  no one take default storage pool
13:08:22 <royce> aglitke, the patch seems reviewed by you..
13:08:35 <royce> but not merged yet, seems
13:08:38 <aglitke> hmm... I will try to find it.
13:08:51 <aglitke> Sometimes patches can fall through the cracks.
13:08:52 <zhoumeina> 1) the mock model and model should check the same parameter
13:09:00 <ming> another one is the storage pool refresh removal.
13:09:37 <aglitke> ming: Is that one of bing bu's patches?  if so, royce will bundle them and submit a series.
13:09:57 <ming> zhoumeina: Absolutely. we need keep them the same behaviour.
13:10:42 <royce> zhoumeina, ming, they are in the pending patch of refresh which can be sent after auto start
13:10:48 <aglitke> yep... I just replied to your patch with a suggested fix./
13:10:49 <shaohef> $ ls /home/shhfeng/iso/test/
13:10:50 <shaohef> ubuntu-12.04-dvd-amd64.iso
13:10:50 <shaohef> I create a storage pool, path is  /home/shhfeng/iso/, it reports test is directory， and capital is 0
13:11:14 <shaohef> not sure this is right.
13:11:32 <aglitke> shaohef: I don't understand
13:11:38 <shaohef> s/capital/capability
13:11:43 <ming> capacity?
13:11:58 <royce> you mean dir pool reports capacity 0?
13:12:04 <shaohef> s/capital/capacity
13:12:06 <aglitke> in test mode?
13:12:06 <shaohef> yes
13:12:10 <zhoumeina> create pool can not support "capacity" now.
13:12:11 <shaohef> no
13:12:19 <shaohef> really mode
13:12:25 <ming> aglitke: I think the issue how can we report capacity for both file directory pool and iSCSI pool.
13:12:29 <royce> zhoumeina, but should be reported
13:12:50 <ming> capacity actually make no sense for file directory pool.
13:13:00 <royce> I mean you don't pass it as a param in create, but it will reported in lookup
13:13:03 <aglitke> shaohef: It should have the same capacity as  'df -h' reports for the filesystem where that directory is located.
13:13:05 <zhoumeina> support capacity for dir is hard>
13:13:23 <aglitke> zhoumeina: libvirt reports capacity
13:13:29 <aglitke> it should work fine.
13:13:49 <aglitke> if it is not, then we might have a bug
13:13:55 <zhoumeina> so why we don't support capacity for dir?? confused
13:14:11 <ming> aglitke: Let me check if that capacity works.
13:14:15 <royce> supported by libvirt
13:14:25 <royce> virsh # pool-info home-pool
13:14:25 <royce> Name:           home-pool
13:14:25 <royce> UUID:           3cb9f467-bbd2-3db9-74bf-fff04390186c
13:14:25 <royce> State:          running
13:14:25 <royce> Persistent:     yes
13:14:26 <royce> Autostart:      yes
13:14:27 <royce> Capacity:       269.09 GiB
13:14:29 <royce> Allocation:     21.50 GiB
13:14:31 <royce> Available:      247.59 GiB
13:14:33 <zhoumeina> not work, bing bu told me that when I do the UI design
13:14:33 <aglitke> yep
13:14:42 <zhoumeina> so I drop the design of capacity
13:14:55 <aglitke> zhoumeina: it should work.  You cannot specify it during create
13:14:57 <ming> I believe Bingbu tested that and found something wrong.
13:14:59 <aglitke> but it will be reported
13:15:28 <ming> aglitke: You refreshed my memory about that.
13:15:31 <aglitke> There is a bug in the MockModel.  It should not expect capacity as a parameter for create.
13:15:48 <royce> right, aglitke
13:15:48 <aglitke> I think the Model works correctly.
13:16:17 <ming> Let's fix mock model bug and keep capacity
13:16:19 <shaohef> aglitke:  do you means
13:16:19 <shaohef> $ du -h /home/shhfeng/iso/test
13:16:19 <shaohef> 1.6G	/home/shhfeng/iso/test
13:16:23 <aglitke> shaohef: If you are still having problems with the display of capacity you should open an issue.
13:17:00 <aglitke> ming: Yep.  See my recent reply to zhoumeina on the ML
13:17:00 <shaohef> aglitke: OK. I'm not sure the capacity should be 0 for dir
13:17:16 <aglitke> shaohef: Right,  it should be > 0
13:17:29 <shaohef> aglitke: OK, got it.
13:17:37 <royce> shaohef, mine is a dir too
13:17:39 <Guest7019> what does capacity mean? if the dir is not the mnt point of a fs, then the space of the fs could be stolen by other files except the vm volumes.  so the capacity for dir is not exact
13:17:49 <aglitke> shaohef: du reports allocated space.  df reports filesystem stats
13:18:15 <aglitke> Guest7019: That is true.  It's a small limitation
13:18:27 <aglitke> But it still gives you an idea of how much space you could use.
13:18:41 <Guest7019> yep, I agree
13:19:09 <aglitke> we can't currently put a quota on the directory.
13:19:44 <shaohef> aglitke: should we support quota on the directory in future?
13:20:10 <royce> Guest7019, according to my test, capacity is my whole mounted space in libvirt
13:20:11 <aglitke> shaohef: No
13:20:17 <aglitke> it's not that important
13:20:29 <aglitke> All: We also have this bug list https://github.com/kimchi-project/kimchi/issues?labels=bug&page=1&state=open
13:20:44 <aglitke> I have tried to close all of the ones we've fixed.
13:20:58 <ming> Let's move the discussion in the bug list.
13:21:17 <aglitke> I have created some local vms for Fedora 19, Ubuntu 13.04, openSUSE 12.3 and RHEL-6.4
13:21:46 <ming> aglitke: for demo?
13:21:48 <aglitke> I would encourage everyone else to test kimchi on other distros so we can fix build and install issues.
13:21:54 <shaohef> aglitke: so we can use your vms for test kimchi
13:21:59 <aglitke> nope. just for testing and development.
13:22:10 <aglitke> shaohef: No.  You'll need to create your owm
13:22:12 <aglitke> own
13:22:21 <Guest7019> royce, yes, but that is inaccurate,  because some of space could be used for other purpose rather than vm volumes.
13:22:32 <royce> aglitke, we'll do and we have env
13:22:38 <aglitke> ming: of course I am not going to review the bug list.  I hope everyone will help to fix them before release though.
13:22:43 <royce> right, Guest7019
13:22:47 <aglitke> royce: great, thanks.
13:22:48 <shaohef> aglitke: guess, Your vms  are not clean for kimchi
13:23:18 <aglitke> shaohef: They are clean, but you can recreate them locally faster than you could download them from me.
13:23:35 <aglitke> they are just clean installs so I can test the kimchi install process.
13:23:59 <aglitke> royce: Did you see: https://github.com/kimchi-project/kimchi/wiki/Testing-1.0
13:24:31 <shaohef> aglitke: so the next week is test week, test bugs and fix bugs?
13:24:36 <royce> that's great
13:24:39 <aglitke> I think it will help us track and fix install issues across supported distros.
13:24:55 <aglitke> shaohef: No.  Next week is the last week for new features.
13:25:01 <ming> aglitke: I think we need list the extra packages which are not in the standard distro realese
13:25:01 <aglitke> we have to finish the above list.
13:25:12 <aglitke> Then we have 2 weeks for bug fixing and release prep.
13:25:34 <ming> for example. we need epel repo to install external packages for RHEL 6.4
13:25:48 <aglitke> ming: Yes -- a good idea.
13:25:58 <ming> I think our final goal is to remove all these external packages.
13:26:03 <royce> right
13:26:07 <ming> Now just list them.
13:26:14 <aglitke> I am glad we are creating individual sections for each distro in the dependencies section of the readme.
13:26:42 <shaohef> ming: epel repo ? what is it?
13:26:52 <aglitke> there should be nothing that kimchi requires that requires unpackaged software.
13:26:58 <aglitke> epel is ok to require.
13:27:18 <royce> shaohef, they are not included in the official repo, but supplied by fedora
13:27:28 <aglitke> shaohef: Extra Packages for Enterprise Linux
13:27:33 <ming> epel is not a official site maintained by Redhat?
13:27:38 <aglitke> ut us
13:27:40 <aglitke> it is
13:28:01 <aglitke> but the packages do not get the same level of support as the core distro
13:28:16 <aglitke> but many people use the epel repos
13:28:32 <ming> Okay, we can treat epel packages as native packages.
13:28:46 <aglitke> yes
13:29:11 <shaohef> aglitke:  epel is not stable
13:29:13 <aglitke> ok.  I want to get you all off to your vacation.  Any other topics to cover?
13:29:21 <shaohef> aglitke: right?
13:29:30 <aglitke> shaohef: It is good enough for our needs right now.
13:29:46 <shaohef> aglitke:no other topics
13:29:47 <aglitke> In future releases, kimchi might be a part of base rhel
13:29:57 <aglitke> ok... anyone else?
13:30:07 <shaohef> aglitke: that's great
13:30:09 <ming> All for me today.
13:30:12 <royce> Good for me now:P I'm eating my moon cake when we are done
13:30:26 <aglitke> ok... Enjoy your holiday!  See you next week.
13:30:32 <aglitke> royce: yum!
13:30:34 <ming> See u.
13:30:37 <royce> :)
13:30:39 <aglitke> #endmeeting