03:00:29 #startmeeting zun 03:00:30 Meeting started Tue Mar 20 03:00:29 2018 UTC and is due to finish in 60 minutes. The chair is fengshengqin. Information about MeetBot at http://wiki.debian.org/MeetBot. 03:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:00:34 The meeting name has been set to 'zun' 03:00:45 #topic Roll Call 03:00:48 o/ 03:00:55 o/ 03:01:22 Thanks for joining the meeting, hongbin, kivenz 03:01:27 :) 03:01:36 :-) 03:01:58 #topic Announcements 03:02:10 Two Zun's presentations were selected at OpenStack Vancouver Summit 03:02:22 1. Build Your Serverless Container Cloud with OpenStack and Kubernetes #link https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/20734/build-your-serverless-container-cloud-with-openstack-and-kubernetes 2. Integration of Openstack Zun with Kata containers #link https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21193/integration-of-openstack-zun-with-kata-containers 03:02:31 * hongbin applaud 03:02:40 #link https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/20734/build-your-serverless-container-cloud-with-openstack-and-kubernetes 03:02:46 #link https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21193/integration-of-openstack-zun-with-kata-containers 03:03:01 thanks hongbin 03:03:04 Cool 03:03:05 congrat kevinz 03:03:15 Thanks :-) 03:03:36 congrat , too 03:03:37 i believe this would be a very good presentation 03:03:55 kevinz: do you confirm the travel to canada? 03:04:16 hongbin: Yes. I can come 03:04:22 awesome 03:04:27 now applying for visa 03:04:39 great news 03:05:21 #topic Blueprints 03:05:36 1. OpenStack as a virtual Kubernetes node (assignee: kevinz) 03:05:54 Hi 03:06:17 hi, how about your presentation to introduce zun in HongKong last week 03:06:30 last week prepared a Zun session in Hong Kong this Friday 03:06:43 is there anything progress about this BP 03:07:06 this session will happen this Friday :-) 03:07:31 Still working on Capsule Create(golang support) 03:08:02 oh, i make a mistake 03:08:03 Meet several test case failed. But now most of them are OK 03:08:27 great news! 03:08:31 beside, I've done a investigation about virtual-kubelet 03:08:36 cool 03:08:53 I'll paste the investigation doc to googledoc 03:09:26 That's all from my side 03:09:56 thanks, kevinz 03:10:07 my pleasure 03:10:21 2. Support remove image in zun (assignee: pengdake) 03:10:36 i believe pengdake is not here 03:10:57 he wanted to discuss his image delete patch (i recalled) 03:11:02 yes 03:11:11 a question for you guys: 03:11:26 I think he is missing policy rule for image_delete api 03:11:29 do you have use cases for the image API (image-create, image-delete, image-show) 03:11:52 hongbin: ping 03:11:59 caisan: hi 03:12:16 caisan: thanks for joining, you are at the right time, we are discussing your patch 03:12:16 yes, we do. 03:12:29 fengshengqin: what are your use cases ? 03:12:50 hongbin: yes, i have implemented the image-delete code 03:13:09 delete image in docker data 03:13:27 interesting 03:13:44 if glance driver, need delete the tar in the specified path 03:13:56 fengshengqin: policy ? 03:14:34 it sounds like this is the operation for cloud admins ? 03:15:01 e.g. cloud admins want to delete image from docker daemon and glance tarball 03:15:31 however, docker daemon and glance tar is hidden from normal users (non-admin) 03:15:43 this sounds like we should make image API as admin API 03:16:04 this is a good idea. 03:16:36 caisan: ack 03:16:40 fengshengqin: ack 03:16:44 caisan: what do you think? 03:16:46 https://github.com/openstack/zun/tree/master/zun/common/policies 03:17:21 hongbin: you means cloud user just can use the image supported by cloud platform? 03:17:57 caisan: normal users would simply run the container with an image 03:18:10 just that? 03:18:15 yes 03:18:34 i believe normal users won't care the specific path of glance tarball 03:18:50 or the docker image stored in a specific compute host 03:19:02 since all the hosts are hidden from normal users 03:19:08 this strategy reminds me of openstack/trove which do the same way of managing database image. 03:19:15 (only admin can list the hosts) 03:19:53 yes, although i am not quite familiar with trove 03:20:25 caisan: for your patch, i believe most of the code will be used, what need to be change is the police 03:20:51 caisan: change the police to make it admin only, that is it 03:21:13 like this: check_str=base.RULE_ADMIN_API 03:22:41 caisan: any comment ? 03:22:44 anything else? 03:23:03 3. Introduce quota for containers (assignee: TBD) 03:23:12 hongbin: yes, i got it. but this cloud be not inconvenience for normal user if they pull the wrong image 03:23:28 sorry guys, i am poor in english :( 03:23:48 caisan: i think zun is for pulling hte image and mange them 03:23:51 typing slowly 03:24:01 caisan: normally users just want to provide the name of the image, and let zun to pull it 03:24:38 if the image is wrong, zun is responsible to deal with it 03:25:11 caisan: think about it in nova, do the users are responsible to pull down the glance image ? 03:25:40 caisan: i believe they are not, nova will manage the glance image tarball internally 03:25:46 hongbin: yes, i got the point. but the user can delete the image in glance. 03:26:16 caisan: yes, this is the same as zun ? 03:27:01 hongbin: so the add the policy , normal user will delete the image in glance or docker if the need ? 03:27:15 caisan: yes 03:27:41 caisan: and i believe they won't have access to docker, so yes, they can delete it in glance 03:27:59 hongbin: well, at least, docker can not be accessed. yes 03:28:15 agree 03:28:36 3. Introduce quota for containers (assignee: TBD) 03:28:56 as i known, Keystone has supportted unified limits in Queen 03:29:05 fengshengqin: this one is assigned to kien and kien doesn't seem to be here 03:29:23 yes 03:29:50 i haven't looked into the unified limits in keystone yet, but this would be an interesting investigation 03:30:12 currently, nova manage the quota itself, not registering the quota to keystone 03:30:30 yes 03:31:28 i don't known how supports it for zun 03:31:46 fengshengqin: no worry, kien will figure it out (i believe) :) 03:32:33 OK, let's discuss this next time 03:32:52 +1 03:32:59 #topic Bugs 03:33:08 1. Cannot create container with kata runtime (assignee: hongbin) 03:33:37 for this one, i believe the kata team is investigating the issue 03:33:54 they doubt that the issue is about the ipv6 support in kata 03:34:10 they are working on patching the runtime and give it another try 03:34:26 that is all about this bug 03:34:32 fengshengqin: ^^ 03:34:57 thanks, hongbin, let's wait for new patch for kata 03:35:09 2. Error on running privsep helper command (assignee: hongbin) 03:35:23 for this one, i have several patches up for reviews 03:35:36 #link https://review.openstack.org/#/c/544155/ 03:35:45 #link https://review.openstack.org/#/c/554021/ 03:36:00 this bug was introduced after the adding of privsep 03:36:21 privsep is the daemon for executing all the shell commands 03:36:30 so we can execute the sudo command? 03:36:39 so this bug basically breaks all the command execution 03:37:05 fengshengqin: in before, yes, but we switch to privsep for security reasons 03:37:19 fengshengqin: right now, all the shell commands are executed by privsep daemon 03:37:43 i got, i will review again. 03:37:50 thanks 03:38:02 #topic Open Discussion 03:38:15 how about containerize for zun? 03:38:32 what do you mean by containerize? 03:39:03 i mean zun is installed in a container 03:39:20 yes 03:39:36 i believe we have BPs for that, let me find the link 03:39:54 #link https://blueprints.launchpad.net/zun/+spec/zun-wsproxy-as-container 03:40:18 #link https://blueprints.launchpad.net/zun/+spec/zun-api-as-container 03:40:27 ok, i will try to do something about it. 03:40:36 cool 03:41:07 now i have a question 03:41:14 go ahead 03:41:37 such as zun will execute df in container 03:42:05 could you explain it a bit? 03:42:06 df get the info of the container, not for the host 03:42:16 oh, i see 03:42:35 zun exec 03:43:00 above is the exec command, would it be useful ? 03:43:30 so zun should send the commant to host, then host return infos to zun which is installed in continer. 03:44:20 i think it is not 03:44:29 you mean the exec command? 03:44:42 zun exec df 03:44:58 this is equals to "docker exec df" 03:45:36 shouldn't it return the info of the container ? 03:45:49 it will return the df info of container 03:46:00 yes 03:46:17 this is what we expect 03:46:18 but i want get the host info 03:46:40 oh, i see 03:46:47 there is an admin api 03:46:49 fengshengqin: you mean docker daemon host ? 03:46:58 $ zun host-list 03:47:16 $ zun host-show 03:47:36 cool 03:47:44 this will return some host information i believe 03:47:58 what about lspci? 03:48:25 this is a good question 03:48:39 all command in zun code which get host info? 03:49:32 fengshengqin: ?? 03:49:44 fengshengqin: don't get your last question 03:51:17 I mean zun has installed in container, when zun execute the lspci/df/..., it will return the info of container 03:51:33 but i want get the info of host 03:52:23 fengshengqin: right now, zun is installed in the host (not in the container) right ? 03:52:31 yes 03:53:01 suppose zun is containerized, it is about the containerization of the zun-api and zun-wsproxy 03:53:16 zun-compute should not be containerized ( i think) 03:53:26 and all the commands are executed by zun-compute 03:53:39 oh,i see. 03:53:41 therefore, zun-compute will execute those commands in host 03:54:13 so we want send the command to host 03:54:20 yes, definitely 03:54:33 This is not a mature idea, I'll think about it, also hope to get your suggestions 03:54:43 sure 03:55:09 anything else? 03:55:31 no from my side 03:55:43 thanks for joining the meeting again, see you next time 03:55:53 fengshengqin: thanks for chairing the meeting, i believe you did a good job :) 03:56:07 thanks 03:56:10 yes, see you all 03:56:33 #endmeeting