03:00:04 #startmeeting zun 03:00:05 Meeting started Tue Jan 31 03:00:04 2017 UTC and is due to finish in 60 minutes. The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot. 03:00:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:00:08 The meeting name has been set to 'zun' 03:00:10 #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-01-31_0300_UTC Today's agenda 03:00:14 #topic Roll Call 03:00:17 Namrata 03:00:19 Shubham 03:01:18 thanks for joining the meeting Namrata shubhams 03:01:49 these weeks are chinese new year, so a lot of folks are vacation right now 03:02:07 hongbin: seems we 3 only. Lets wait for a minute or two for others to join . 03:02:13 Hongbin, I am here also 03:02:21 hey lakerzhou 03:02:38 yes, let's wait for a minute 03:02:49 o/ 03:02:55 diga: hi 03:03:04 hongbin: Hi 03:03:07 ok, let's have a short meeting this week 03:03:13 #topic Announcements 03:03:18 1. Welcome Kevin to the core team 03:03:27 #topic Review Action Items 03:03:31 Hi 03:03:34 Sorry I am late 03:03:36 1. hongbin create a bp for exposing container cpu resource (N/A, a BP was already created) 03:03:41 Welcome kevin 03:03:51 mkrai: hi mkrai , thanks for joining the meeting 03:03:58 #link https://blueprints.launchpad.net/zun/+spec/cpuset-container Support pinning container to CPU cores 03:04:12 2. hongbin create a bp to add support for expose container port (DONE) 03:04:18 #link https://blueprints.launchpad.net/zun/+spec/expose-containerized-app 03:04:27 any question about these two action items? 03:05:03 seems not. next topic 03:05:05 #topic Cinder integration (diga) 03:05:10 #link https://blueprints.launchpad.net/zun/+spec/cinder-zun-integration The BP 03:05:15 #link https://review.openstack.org/#/c/417747/ The design spec 03:05:22 diga: ^^ 03:05:28 yes 03:05:41 diga: any update from your side about hte cinder integration? 03:05:51 hongbin: I am working on it, but last week i was busy product release so couldn't get time 03:06:02 diga: np 03:06:12 I am starting today on it, as yesterday we shipped the release 03:06:30 diga: thanks diga 03:06:42 hongbin: one more thing, I got official support from my company to contribute to OpenStack 03:06:55 diga: good to hear 03:06:58 o/ 03:07:05 hongbin: I think today onward I can spend at least 2 hours 03:07:05 sudipto_: hey 03:07:14 sorry a little late today. 03:07:22 diga: great 03:07:25 sudipto_: np 03:07:38 hongbin: just one question on driver 03:07:50 diga: go ahead 03:08:15 hongbin: as we are writing driver for image, storage, networking etc 03:08:47 hongbin: can we have center driver folder & under that we can create multiple drivers 03:08:49 ? 03:09:21 drivers/images driver/volumes drivers/networks etc 03:09:33 to keep the design simple 03:09:49 I think that can be done 03:09:54 i think nova is using this structure 03:10:01 Yes 03:10:12 images/driver volumes/driver networks/driver 03:10:38 I started reading code. It sounds a good idea to me. 03:10:55 okay 03:11:40 I think this design structure we should follow going ahead 03:11:41 diga: however, i think container driver is the only important driver for us 03:11:54 hongbin: okay 03:12:01 diga: we are not writting drivers for network and volume (kuryr does) 03:12:23 diga: but feel free to propose the folder change if you think it is better 03:12:24 hongbin: okay 03:12:41 hongbin: Sure 03:12:58 hongbin: Thanks 03:13:00 diga: any other question from you? 03:13:08 hongbin: No, I am done! 03:13:17 thanks diga 03:13:24 #topic Kuryr integration (hongbin) 03:13:29 #link https://blueprints.launchpad.net/zun/+spec/kuryr-integration The BP 03:13:40 i give a short update of this one 03:13:59 i have wrote down the spec, and needs a few patch from kuryr side to merge 03:14:33 all, feel free to comment on the spec if you like 03:14:41 will go through the spec 03:14:47 #link https://review.openstack.org/#/c/425883/ 03:14:55 What patches from Kuryr side? 03:15:14 #link https://review.openstack.org/#/c/426595/ 03:15:20 above is the kuryr patch 03:15:42 Ok got it 03:15:43 mkrai: I think idea is same as we have proposed for volume integration, we are not going to call kuryr API 03:16:27 hongbin: am i correct ? 03:16:36 diga: i think you are 03:16:58 yep 03:17:04 ok, advance topic 03:17:08 #topic Support interactive mode (kevinz) 03:17:20 it looks kevin is on vacation 03:17:24 skip this one 03:17:29 #topic The image API (prameswar) 03:17:34 #link https://review.openstack.org/#/c/425249/ 03:17:36 hi 03:17:41 Currently, we are storing image data in db. instead of db we can use storage driver for that as we discussed before. 03:18:25 we can support multiple image driver 03:18:37 to store image 03:18:51 what you guys think ? 03:18:54 prameswar: By storage driver, you mean? 03:19:28 sorry image driver 03:19:34 like docker store images 03:19:42 prameswar: you mean you want to store image in object store ?? 03:19:58 kind of 03:20:25 i am not sure what exactly but db not seems good 03:20:34 to me 03:20:46 We are just storing the image info in db 03:20:58 We have glance/docker to store images 03:21:27 but i think docker store image info in some json format 03:21:32 if i am not wrong 03:21:41 it don't use database 03:21:43 this is good thing to store in glance 03:21:59 yes 03:22:41 prameswar: right now, image API has list/show/pull/search 03:22:46 prameswar: Any pitfalls or disadvantages you see having info stored in db? asking as only basic info is stored in db as of now 03:23:16 prameswar: if we skip the db, than all these operations are got from dockerhub/glance, is that correct? 03:23:47 i think so 03:23:51 prameswar, yes docker stores them in json blob, but why do we have to change for that? 03:24:37 I dont see any problem in storing image url info in db 03:24:41 i think the problem right now is that the image api is not able to handle the multi-host senario 03:24:59 hongbin: Yes that is a valid point 03:25:01 e.g. zun image-search : it search image in one host 03:25:03 hongbin: correct 03:25:36 i guess this is a motivation mentioned in the review 03:25:53 okay 03:26:11 it seems prameswar 's proposal could solve the problem (although i haven't think about it carefully) 03:26:45 prameswar: i think you can propose a spec if you want to do that 03:26:49 let me spend some time on this . i will collect some more info then will let you know 03:27:04 yes , sure 03:27:20 +1 for spec 03:27:31 yes, then we can discuss on the spec 03:27:56 I will go through the spec today 03:28:01 any other comment about this topic? 03:28:41 ok, next topic 03:28:49 #topic Discuss BPs that are pending approval 03:28:54 #link https://blueprints.launchpad.net/zun/+spec/support-blkio Support blkio 03:29:43 i didn't get a chance to study the blkio option yet 03:29:50 anyone else has a comment on this one? 03:30:05 It seems that it will be good to support 03:30:17 mkrai: ack 03:30:19 Doesn't have much details? 03:30:42 sudipto_: no, it doesn't 03:30:50 what use case we solve using this BP ? 03:31:03 i am not sure exactly what was proposed.... 03:31:18 okay 03:31:22 limit the IO operation per container 03:31:29 ok, let me ask for clarification in the bp before approving it 03:31:36 ok 03:31:58 we should explore more on this 03:32:05 any other comment? 03:32:20 #link https://blueprints.launchpad.net/zun/+spec/support-zun-stats Support stats 03:32:50 IMO, this is a good addition. 03:33:04 sudipto_: ack 03:33:13 There is patch already for this 03:33:20 sudipto_: do you know the docker stats command well? 03:33:35 sudipto_: what this command is going to do? 03:33:48 No that is for top. Sorry 03:33:59 hongbin, yeah sort of. This should you the top command equivalent data of sorts. 03:34:08 but for each docker container. 03:34:23 sudipto_: is the data streaming from server to client? 03:34:42 hongbin, yes. 03:34:56 sudipto_: i see 03:35:00 it does not give you a snapshot, rather a continuous stream. 03:35:12 i guess that's what you asked. 03:35:19 sudipto_: yes 03:35:32 i am not sure how to implement it then, since it is streaming 03:36:02 also, i am not sure how to handle the multi-host senario 03:36:14 does docker expose stats API ? 03:36:15 does the data streaming from multiple hosts? 03:36:22 diga: Yes 03:36:30 ok 03:36:36 sudipto_: ^^ 03:36:51 hongbin, I haven't tried this on multiple hosts. 03:36:59 :) 03:37:04 Who will consume the stats data? Apps such as ceilometer? 03:37:21 lakerzhou: i don't know that as well 03:37:31 lakerzhou, i guess yes. But that way zun command line may not be needed to support it. 03:38:09 in that case, if docker shows stats for one docker endpoint, so in this case, we can accept docker host & for the first time, we should accept one docker host to display stats 03:38:48 streaming from multiple hosts we can think more 03:38:48 stats is per container 03:38:56 diga: host should be an admin-only api (at least in nova) 03:39:12 hongbin: okay 03:39:16 Maybe this is a better fit in Ceilometer? 03:39:19 mkrai: i think top is per container? 03:39:30 sudipto_: not sure 03:40:03 hongbin: Display a live stream of container(s) resource usage statistics 03:40:18 mkrai: ok 03:40:50 all, should this bp be approved/disapproved, or table it? 03:41:05 Then the multiple host issue is not valid I guess 03:41:17 i see 03:41:22 hmm 03:41:29 I think we need to look how do we handle the live streaming? 03:41:34 from docker daemon to zun 03:41:43 yeah 03:42:18 this would not be easy, might be something similar to what kevin was doing (interactive mode) 03:42:32 Yes 03:42:32 there are other libraries support live streaming we can use those, but it will be dependancy in zun 03:43:03 We can ask the author of bp to see the feasibility of doing this in zun 03:43:12 sure 03:43:16 +1 03:43:19 then, let's table this bp 03:43:33 yep 03:43:40 until we get the answer from the author 03:43:52 #topic Open Discussion 03:43:53 this is good addition to Zun 03:43:53 hongbin: +1 03:44:11 all, any other topic to discuss 03:44:26 hongbin: are we planning for PTG ? 03:44:39 I just posted a spec here: https://review.openstack.org/#/c/427007/2/specs/cpuset-container.rst (It's pretty much out of my head atm) - please take a look when you can. 03:44:48 diga: no, zun won't attend the ptg 03:45:03 hongbin: okay 03:45:23 sudipto_: cool 03:45:27 i have posted a patch to add zun resources https://review.openstack.org/#/c/426210/ 03:45:58 This is an attempt to build host capabilities in zun as well. I will keep refining the spec as we go. Let me know if there' sa need for a separate BP all together for host capabilities. 03:46:01 Namrata: awesome! 03:46:27 thanks.it is up for review 03:46:46 sudipto_: i think the host capabilities worth a separated spec, it would be a lot of work 03:47:14 yeah i have wrote down very minimalistic things, I am guessing you'd have to help me out co-authoring some of the stuff hongbin 03:47:27 sudipto_: for sure 03:47:42 #action hongbin create a spec for host capability 03:48:09 i guess a lot of code will be copied from nova :) 03:48:26 hongbin, yeah maybe, we probably wouldn't need many things as well. 03:48:45 yes 03:48:55 ok, any other topic? 03:49:17 today, many chinese folks are not able to come due to the chinese new year 03:49:31 Happy chinese new year hongbin :) 03:49:35 then, let's end the meeting a bit earlier 03:49:45 mkrai: thank you :) 03:49:46 Happy new year hongbin :) 03:49:54 thanks 03:50:00 hongbin: Happy New year! 03:50:09 all, thanks for joining hte meeting 03:50:12 #endmeeting