03:00:02 #startmeeting zun 03:00:03 Meeting started Tue Jun 6 03:00:02 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:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:00:06 The meeting name has been set to 'zun' 03:00:09 #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-06-06_0300_UTC Today's agenda 03:00:13 #topic Roll Call 03:00:24 lakerzhou 03:00:33 shunli 03:00:33 Namrata 03:00:40 Madhuri 03:00:48 Shubham 03:00:51 kevinz 03:01:15 thanks for joining hte meeting lakerzhou2 Shunli Namrata mkrai shubhams kevinz 03:01:21 let's get started 03:01:27 #topic Announcements 03:01:37 anyone has an announcement? 03:01:58 seems no 03:02:02 #topic Cinder integration 03:02:08 #link https://blueprints.launchpad.net/zun/+spec/direct-cinder-integration Direct Cinder integration 03:02:13 #link https://blueprints.launchpad.net/zun/+spec/cinder-zun-integration Cinder integration via Fuxi 03:02:37 for this topic, i proposed to have two drivers for handling volumes 03:02:48 1. cinder, 2. fuxi 03:03:07 there is a review up for that: https://review.openstack.org/#/c/468658/ 03:03:18 o/ 03:03:28 hi diga 03:03:35 hongbin: Hello 03:03:40 comments on this topic? 03:04:16 hongbin: I will push the latest patch today by incorporating given comments 03:04:25 diga: ack 03:05:01 hongbin: If i need any help in gate passing, will ping you 03:05:11 diga: ok 03:05:45 hongbin: that's it from my side 03:05:48 ok, everyone, you could spend your time to review hte spec after th e meeting 03:05:58 and provide your feedback on the review 03:06:01 OK I will review this 03:06:03 #link https://review.openstack.org/#/c/468658/ 03:06:17 kevinz: thank you 03:06:20 ok, next topic 03:06:29 #topic Introduce container composition (kevinz) 03:06:41 kevinz: want to drive this one? 03:06:48 hongbin: sure 03:07:16 I have one topic to discuss. That's from the comment of lakerzhou in the spec 03:07:17 https://review.openstack.org/#/c/437759/17/specs/container-composition.rst@73 03:07:43 We have : CPU and memory limits: Given that host resource allocation, cpu and memory limitation 03:07:43 support will be implemented. 03:08:18 Lakerzhou has a comments : With the limits, the CPU/RAM usage of the capsule will never beyond the number, but do we have any grantee that how much resources allocated to a capsule? Should we use resources instead of limits here? 03:09:10 lakerzhou2: could you clarify " Should we use resources instead of limits here?" 03:10:11 for the first question, i think filter scheduler will ensure the amount of resources allocated to a container/capsule 03:10:19 I think limits meaning the containers will take less resource than the limit 03:10:44 that is true 03:11:01 but in fact, resources is what the containers require from the host 03:11:22 yes 03:11:39 Limit is on the resource. Right? 03:11:55 lakerzhou2: but the scheduler will schedule containers based on resources on the host? 03:11:57 I don't get the correlation here 03:12:36 yes, why use limits, does that mean container might take less resources? 03:13:41 for example, if a container requires 2 vcpus, scheduler should assign 2 vcpus 03:13:51 i see 03:14:06 lakerzhou2: Per my understanding, you mean we should add a field to control the "at least" resources for container? 03:14:32 no, I don't see a reason to use "limits" 03:15:01 resources: vcpus: 2, ram: 3G 03:15:49 perhaps just remove the "limits" from the naming, call it cpu/memory 03:16:14 that is what I meant 03:16:33 yes, i am fine with that 03:16:37 hongbin: I thinks it's fine, we can remove 03:16:53 kevinz: ok 03:17:17 any opposing point of view on this? 03:18:16 lakerzhou2: i think this is a good suggestion. thanks lakerzhou2 03:18:47 np, 03:18:49 kevinz: anything else about this topic? 03:19:07 hongbin: No, that's all from me 03:19:45 kevinz: ok, hope you get enough feedback to get started 03:20:01 kevinz: thanks for driving this effort :) 03:20:15 hongbin: thx hongbin, my pleasure:-) 03:20:27 next topic 03:20:29 #topic Add Zun Resources to Heat 03:20:34 #link https://blueprints.launchpad.net/heat/+spec/heat-plugin-zun 03:20:49 Namrata: you want to chair this topic? 03:20:55 Yeah sure 03:21:03 https://review.openstack.org/#/c/437810/ 03:21:11 I have updated the patch 03:21:22 there are some more comments which I will incorporate 03:21:48 cool 03:22:29 i think the patch looks pretty close to merge 03:22:30 and as discussed in earlier meeting I am also working on the heat doc for zun 03:22:42 Hongbin : Yes 03:22:51 great 03:23:18 That's it 03:23:34 Namrata: thanks Namrata 03:23:43 thanks hongbin 03:23:44 all, any comment on this topic? 03:24:20 seems no 03:24:25 #topic Others 03:24:31 #link https://blueprints.launchpad.net/zun/+spec/make-sandbox-optional Make infra container optional 03:24:56 i wanted to bring up this one to see if you think this is a good idea/bad idea 03:25:16 a brief introduction 03:26:01 the concept of sandbox, which is an infra container, is used to present the container that doesn't do anything but just provide the infra 03:26:08 i.e. kubernetes/pause 03:26:39 there are feedback to suggest to make it optional when we don't need it 03:26:53 This is a good idea, I got feedback from Intel's clear container team as well 03:27:05 mkrai: ack 03:27:05 I vote for making it optional 03:27:13 lakerzhou2: ack 03:27:28 any opposing point of view? 03:28:08 ok, if this is optional, we can remove it on naitive docker driver 03:28:28 this is needed for capsule and nova driver only i guess 03:29:00 hongbin: yeah, make it optional is OK 03:29:11 kevinz: ack 03:29:24 ok, seems everyone agree on this proposal 03:30:05 #agreed make snadbox optional for drivers that are not needed 03:30:33 btw, pls feel free to take that bp if you interest to do it 03:30:56 i will be the default owner if nobody want to take it 03:31:09 ok, next bp 03:31:18 #link https://blueprints.launchpad.net/zun/+spec/infra-container-in-db Persist infra container in DB 03:31:56 this one is proposed by me as well 03:32:09 and there is a patch available for that 03:32:28 #link https://review.openstack.org/#/c/467535/ 03:32:44 there are some debate on the review 03:32:59 therefore, i summarize the opinions into the whiteboard 03:33:04 hongbin: What is the need for this? 03:33:27 mkrai: we want to have a way to keep track of the infra container 03:33:46 mkrai: or later, if we use vm as sandbox, we need to keep track of all the vms as well 03:34:02 Ok 03:34:22 there are three implementation options 03:34:48 OPTION 1: 03:35:06 Add a field (i.e. infra_container_id) into the container table. If a container is infra container, this field is None, otherwise, it points to the uuid of its infra container. 03:35:25 OPTION 2: 03:35:34 Create a separated table for infra container 03:35:41 OPTION 3: 03:35:51 Same as option 2 but leverage the concept of 'capsule' instead 03:36:28 i think option 2/3 are almost the same, the different is the naming of hte table 03:36:37 name it sandbox or capsule 03:36:49 thoughts on this? 03:37:07 hongbin: In #2, we need to have relation b/w container and infra container 03:37:16 But how is that done? 03:37:46 mkrai: i assume there is a foreigh key in the container table to point to the sandbox id 03:38:24 hongbin: So what info of infra contaienr we want to save? 03:39:01 Because it only makes sense to have new table only when we want to store all info related to a infra_container 03:39:08 Otherwise #1 is better 03:39:28 mkrai: this is a good question 03:40:11 i haven't given it a careful thought in before 03:41:21 I can check the patch today 03:41:26 anyone has comments on this? 03:41:26 And leave my comment there 03:41:36 mkrai: ok, thx 03:42:19 i think if not everyone agree on the idea, we could table this bp for now 03:42:36 and bring it back when someone interest in it 03:42:51 I am ok with it 03:43:17 kevinz: from capsule point of view, which option wil lbe better? 03:43:38 kevinz: or you think we don't need to persist this info to db 03:44:46 ok, never mind, we need to move on to the next one 03:45:07 kevinz: you can comment on the review later 03:45:09 #link https://etherpad.openstack.org/p/zun-nfv-use-cases NFV use cases 03:45:28 lakerzhou2: you want to drive this one? 03:45:49 sure 03:46:36 I did not have much input lately, but the core idea is to support VNF workload over containers 03:47:06 #link https://review.openstack.org/#/c/465661/ 03:47:09 VNF usually requires CPU pinning, huge page and NUMA support 03:47:43 which will need some support from scheduler 03:48:44 sounds great, I will review the kuryr spec 03:48:46 i think Shunli might interest to help out the scheduler part ? since he worked on the filter scheduler 03:48:57 to see how we can leverage the work with zun 03:49:13 sure. 03:49:22 lakerzhou2: oh, it is about k8s 03:49:46 lakerzhou2: if we want to leverage it, i might need to figure out if libnetwork should support the same 03:50:11 ok, I will explore the possibility 03:50:52 lakerzhou2: i think the requirements for this is very clear since it is all listed in the etherpad 03:51:20 lakerzhou2: the next step is to turn the requirements into bps, so that i could find contributors to work on them 03:51:43 ok, I will work on it 03:52:05 thanks, i will help out this part as well 03:52:27 will work on the Action items session in the etherpad 03:52:36 Hongbin, thanks, I will ping you on IRC 03:52:43 lakerzhou2: ack 03:53:01 everyone, any comment on this topic? 03:53:28 No 03:53:36 Will see the etherpad 03:53:43 no 03:53:47 Thanks lakerzhou2 03:53:49 mkrai: thx 03:54:00 btw, this spec has been there for a while: https://review.openstack.org/#/c/427007/ 03:54:03 #link https://review.openstack.org/#/c/427007/ 03:54:16 i think it is time to move it forward 03:54:35 this could be the first step for the nfv support i think 03:54:58 #topic Open Discussion 03:55:26 anyone want to bring up a discussion? 03:55:33 To support clear container in Zun, I have posted a patch in docker-py to support --runtime option 03:55:43 #link https://github.com/docker/docker-py/pull/1631 03:56:07 And would want the infra container to be removed 03:56:19 mkrai: ok 03:56:52 mkrai: i think we need to bump the priority for bp to make infra container optional 03:57:01 hongbin: Right 03:57:02 since everyone wanted it gone 03:57:05 :) 03:57:17 done 03:57:27 I will see if I can do it :) 03:58:37 mkrai: sure, take it if you have time 03:58:56 hongbin: Sure. Thanks 03:59:13 ok, everyone, thanks for joining the meeting 03:59:27 see you next time 03:59:30 #endmeeting