03:00:05 #startmeeting zun 03:00:06 Meeting started Tue Jul 18 03:00:05 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:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:00:09 The meeting name has been set to 'zun' 03:00:10 #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-07-18_0300_UTC Today's agenda 03:00:15 #topic Roll Call 03:00:26 Namrata 03:00:42 Madhuri 03:00:54 kevinz 03:01:28 thanks for joining the meeting Namrata mkrai kevinz 03:02:03 ok, let's get started, potentially a short meeting 03:02:07 #topic Announcements 03:02:14 1. No meeting at 2017-07-25 due to OpenStack Days China. 03:02:20 #link http://openstackdaychina.org/ 03:02:29 2. New BPs created 03:02:35 #link https://blueprints.launchpad.net/zun/+spec/show-container-engine-info Introduce an API to show container engine info 03:02:51 that is all the announcement from my side 03:03:17 any comment? 03:03:41 seems no 03:03:43 hongbin: I wanted to know what this BP about 03:03:50 mkrai: sure 03:03:55 I think we can take it in open discussion 03:04:01 Need time to read it 03:04:15 i remembered i created this bp based on a question from ML 03:04:27 yes I also read that email 03:04:37 ok 03:04:54 any other comment? 03:05:13 ok, next topic 03:05:15 #topic Cinder integration 03:05:42 i didn't have time to work on this one recently, due to openstack day china preparation 03:05:55 i will get back to this after the event 03:06:14 i am planning to move to the new cinder attachment workflow 03:06:46 which is hte new attachment workflow that nova is switching to it 03:07:07 What is it? 03:07:13 Is there any spec for it in Nova? 03:07:27 #link https://review.openstack.org/#/c/330285/ 03:07:48 the implementation will be something like above patch 03:08:14 i believe there is a spec, but couldn't find it at the monent 03:08:17 I am not sure what the change is about but its always good to go with the latest changes 03:08:31 ack 03:09:00 any other comment before going to the next topic? 03:09:08 no 03:09:14 #topic Introduce container composition (kevinz) 03:09:22 hi all 03:09:22 kevinz: ^^ 03:09:44 I've split the patch of zun capsule to several patch 03:10:00 support capsule create, list ,describe and delete 03:10:32 cool 03:10:39 I find that the image searching and image load will cost a little long time 03:11:23 how long? 03:12:19 It feels like half of time will be cost by image load and search 03:12:54 image searching is for validation only 03:13:12 The time of capsule creation will cost 10s I find 03:13:14 if performance is suboptimal, we could figure out a way to disable it 03:13:23 i see 03:13:32 10s is long time 03:13:46 Yes we can disable the image validation 03:14:12 OK that's good news 03:14:52 where to disable it? by configuration? 03:14:54 for image loading, i think it might be possible to check if an image is already loaded, before loading hte new image 03:15:24 however, it will miss if there is a new image available at docker hub 03:15:26 no there is no such config now kevinz 03:16:09 hongbin: i think we are talking about the image validation at the api layer 03:16:18 isn't it? 03:16:44 mkrai: yes, sorry, i commented on the loading , which is too fast 03:16:53 ok, back to the api validation 03:17:05 hongbin: np :) 03:17:23 yes, a config will work 03:17:46 hongbin: I am think how about removing it? 03:17:53 an alternative approach is introducing a option like: zun run --no-validation nginx 03:18:22 let it fail after returning the call, if image is not foung 03:19:02 mkrai: then, users have to do another api call to check if hte container was failing 03:19:32 hongbin: yes the same way it is done for another failures 03:19:40 #link https://github.com/openstack/zun/blob/master/zun/api/controllers/v1/containers.py#L239 03:20:11 Because the image searching is a heavy operation and it blocks the api server 03:20:37 Irony is I added this support if I remember correctly ;) 03:21:07 from user experience point of view, this validation is good for fail earlier 03:21:22 however, if it is too heavy, i am ok to remove it 03:21:36 Yes I agree to that part but we can't underestimate the time consumption 03:21:54 I think its better to add a config. WDYT? 03:22:07 yes, that will work as well 03:22:48 kevinz: hongbin I can post a patch for that if you want 03:23:22 mkrai: sure, np from me 03:23:33 mkrai: Thanks 03:23:44 hongbin: Ok what should be the default value? 03:23:54 validation or no validation? 03:24:10 mkrai: i voted for validation by default 03:24:34 +1 03:24:34 Ok agree 03:24:36 hongbin: Can you note a AI for this? 03:24:49 sure 03:25:09 hongbin: Thanks 03:25:29 #action mkrai works on a patch to make image validation configurable 03:25:50 ok, then let's talk about image loading 03:25:58 OK 03:26:18 i think a solution is to load the image only if it is not loaded 03:26:46 We might miss the latest image 03:27:06 yes, that is the drawback 03:27:06 I think this can also be made configurable 03:27:19 whether user wants to use the existing image or the latest image always 03:28:03 yes, i believe a config will work 03:28:36 i was thinking to extend the --image-pull-policy to determine if the image should be loaded 03:28:43 which is another option 03:28:52 yeah that is also an option 03:29:01 in that case we might not need the new config 03:29:17 I actually forgot the image_pull_policy 03:29:58 for loading, this would be image_load_policy, or combine these two option, would be image_policy 03:31:10 I think it is a good solution 03:31:38 ok 03:32:06 Wouldn't the image_pull_policy be enough? I can't think of the use case of both in broader term now 03:32:33 i see 03:32:54 then, load the image only if the image is pulled? 03:33:05 yes 03:33:11 exactly 03:33:13 sound reasonable 03:33:17 mkrai: +1, the image_pull_policy is good enough (sorry if i interrupted) 03:33:32 good 03:34:02 is anything change we need to make? 03:34:13 I think no 03:34:45 kiennt_: hey, thanks for joining hte meeting 03:35:05 mkrai: ack, wait for kevinz to confirm 03:35:19 hongbin: hi, my pleasure. 03:35:45 Actually I 'm not very clear about the image policy. I will check code to see the procedure 03:36:02 kevinz: ack 03:37:36 for capsule, that's all from me 03:37:51 kevinz: thanks 03:38:14 hongbin: my pleasure 03:38:21 kevinz: i remembered we loaded the image only if it is pulled from glance 03:38:23 kevinz: thanks 03:38:50 mkrai:my pleasure 03:38:56 kevinz: for docker hub, it is not loaded 03:39:07 kevinz: ok, you could check that after 03:39:14 hongbin: OK, I will try this after the meeing 03:39:41 #topic Open Discussion 03:39:43 thanks hongbin mkrai 03:40:11 hongbin: when will arrive at Beijing? 03:40:23 kevinz: sunday afternoon 03:40:48 hongbin: OK I'm the same 03:41:10 kevinz: i heard beijing is very hot right now 03:41:12 :) 03:41:39 ok, any other topic to discuss? 03:41:57 hongbin: haha, a little, this weekend will be cool 03:42:02 Yes 03:42:16 about the api to show container engine info 03:42:23 mkrai: go ahead 03:42:56 I think we can use the docker info api for each compute node? 03:43:19 mkrai: i think that is possible 03:44:04 Actually I am thinking of how it will be implemented 03:44:10 I will wait for the patch and see 03:44:26 i think it will be similar as nova hypervisor-show 03:44:55 Yes it should be 03:45:12 i saw shunli is taking the bp 03:45:34 Yes ok let's discuss when Shunli is present 03:45:40 hongbin: I just noticed Shunli's patch set for add volumes_from suppport was abandoned by himself. Why he did that? 03:46:20 kiennt_: he mentioned in the review that this option won't work for mult-host senario 03:46:43 multi-host scenario 03:47:25 for example, if a container in host A, --volume-from container in host B 03:48:19 which is the case that it won't work well 03:49:08 any other topic? 03:49:13 hongbin: I got it, thank you. I didn't read all comments carefully, my bad. 03:49:28 kiennt_: np 03:49:53 ok, it looks no more question 03:50:20 all, thanks for joining the meeting, remember there is no meeting next week 03:50:26 see you next time 03:50:30 #endmeeting