03:00:05 #startmeeting zun 03:00:06 Meeting started Tue Jun 20 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-06-20_0300_UTC Today's agenda 03:00:14 #topic Roll Call 03:00:18 kevinz 03:00:24 o/ 03:00:38 lakerzhou 03:01:24 NAmrata 03:01:40 thanks for joining kevinz mkrai lakerzhou Namrata 03:02:00 ok, let's get started 03:02:17 #topic Announcements 03:02:32 i have an announcement 03:02:52 i and kevinz will present at openstack day china next month 03:03:08 both of us has an accepted presentation about zun 03:03:16 Great :) 03:03:21 great 03:03:30 that is all from my side 03:03:46 any announcement from you? 03:03:53 No 03:03:58 will you please share the slides? 03:04:19 lakerzhou: sure, i will share mine after the presentation 03:04:30 lakerzhou: me too 03:04:45 hongbin and kevin, thanks 03:04:50 ok 03:04:56 #topic Cinder integration 03:05:18 i am working on a WIP patch to introduce cinder integration 03:06:16 i don't think it is ready to be reviewed yet, but the idea is there 03:07:05 basically, the idea is to connect to the cinder volume and bind-mount it to the container 03:07:18 the high level idea has been outlined in a spec 03:07:29 #link https://review.openstack.org/#/c/468658/ 03:07:47 a WIP patch will be ready to be reviewed soon 03:07:59 that is all from me for this topic 03:08:05 any question? 03:08:12 Thanks Hongbin. I will be happy to review 03:08:30 mkrai: thanks madhuri 03:08:43 I think I have one but that might be a vague question 03:08:57 mkrai: go ahead 03:09:23 After reeading the spec, why do we have to use os-brick? Cinder doesn't provide the same device info? 03:09:57 os-brick is the library to connect to different cinder backend 03:10:25 the connection code will be very different for each backend, and os-brick provides a abstracted layer for that 03:10:48 I see 03:11:02 os-brick is just a library? 03:11:15 yes, it is a library (not a service) 03:11:30 Ok thanks for the information 03:11:35 and it is maintained by the cinder team 03:11:58 ok, move on to the next topic 03:12:04 #topic Introduce container composition (kevinz) 03:12:09 #link https://review.openstack.org/#/c/437759/ The design spec 03:12:14 #link https://etherpad.openstack.org/p/zun-container-composition The etherpad 03:12:18 kevinz: ^^ 03:12:38 I have several questions to discuss 03:13:15 First is about the Object and db models of Capsule 03:13:57 go ahead 03:14:09 Does caspule need to include the container uuid? Or container object store a capsule uuid 03:15:05 Capsule should store the container uuid 03:15:37 kevinz: from my perspective, it is better to make container's data model independent, so agree with mkrai 03:16:07 OK, now I plan to use this: 'containers': fields.ListOfObjectsField('Container'), 03:16:31 sounds like a good option to try 03:16:33 Capsule store the container Object entry 03:16:58 Or just a List of container uuid 03:17:33 what is container object entry? 03:18:10 capsule.containers will point to the container 03:18:25 i mean is it a dictionary or something else? 03:19:19 mkrai: I think it is a Object List 03:20:23 If we have decided to keep the container and capsule object independent. It will be good to store the container object itself 03:21:30 mkrai: i think in db level, the capsule object will have a fields called "containers", which is a list of container objects 03:21:38 sorry, in object level 03:22:05 hongbin: that's what I mean. Thanks hongbin 03:22:15 i guess that is what kevinz mean as well :) 03:22:55 ListOfObjectsField is actually a list of "container" object per my understanding 03:24:06 yes it is 03:24:22 mkrai: still have doubt? 03:24:29 No 03:24:34 Got it. Thanks 03:24:55 So I suggest to store container object in capsule db 03:25:15 oh, in db level 03:25:44 yes 03:26:36 mkrai: just want to clarify, what is the goal for this proposal? 03:26:58 keep container and capsule db independent 03:27:17 i see 03:27:39 The same as you suggested :) 03:27:48 i think we can take this proposal as a homework, and eveyone give it more thoughts 03:28:16 OK 03:28:56 kevinz: mkrai i did have some thoughts about the capsule feature, i think it is better to make it as an add-on 03:29:34 kevinz: mkrai like a api extension 03:29:44 hongbin: Would you like to tell it now? 03:30:39 kevinz: mkrai i think this will make the end-users to tell the difference between "container" and "capsule", contianer-api is the core api, capsule is an add-on 03:31:25 kevinz: mkrai i guess that is how it works in neutron (core api, extension) 03:31:47 I am in favor of this idea 03:32:15 Otherwise mixing container and capsule might get complicated in future as well 03:32:25 So its better to keep them independent 03:33:04 I'm OK also, so that all tha API will be separated? 03:33:27 Yes I think so 03:33:31 kevinz: just an initial idea, there will be a zun-api and zun-capsule-api 03:34:13 kevinz: like a docker core api, and the swarm api 03:34:37 (swarm api is an add-on) 03:35:04 +1 03:35:06 (if swarm mode is disabled, there is just docker core api) 03:35:49 hongbin: I see. It's a good point. We can decide to separate it, I think much work need to do 03:36:16 kevinz: :) yes 03:36:22 hongbin: So that the in the db level, container and capsule will separated? 03:36:42 and capsule will maintain its own containers? 03:37:04 kevinz: from my point of view, separation in api level is important, the data model is optional 03:38:03 hongbin: got it. I think so. That will reduce the API cost as well 03:38:34 kevinz: ack 03:39:16 kevinz: btw, let's keep the disucssion open for this idea 03:39:47 hongbin: ack:-) 03:39:57 ok, anything else on this topic? 03:40:08 a small one 03:40:15 go ahead 03:40:17 I plan to place the yaml abstract functions in API server side. 03:40:48 Just mkrai referred in last meeting 03:40:49 ok 03:40:57 That's all from my side 03:41:13 Thanks kevinz for the consideration :) 03:41:20 thanks kevinz 03:41:47 Namrata: ready to talk about your htea integration work? 03:41:51 mkrai:hongbin: Thanks for your help 03:42:01 yeah sure hongbin 03:42:09 Namrata: go ahead 03:42:13 #topic Add Zun Resources to Heat 03:42:38 https://review.openstack.org/#/c/437810/ 03:42:50 Add Container to Zun resources 03:42:53 lakerzhou: will talk about nfv as the next topic if you are still there :) 03:42:57 Hongbin update the patch 03:43:03 *updated 03:43:20 Thanks for that 03:43:26 I am still online 03:43:37 I think only comments need to be incorporated 03:43:45 So hope to get this merged this week 03:43:52 sorry I got very late in joining the meeting 03:44:04 Namrata: thanks Namrata 03:44:21 diga: hey, thanks for joinning 03:44:38 ok, next topic 03:44:40 hongbin: Hi 03:44:42 #topic NFV use cases 03:44:46 #link https://etherpad.openstack.org/p/zun-nfv-use-cases 03:44:55 lakerzhou: want to drive this topic? 03:45:13 I am try to tackle SR-IOV use case for container first because it is relatively simpler than DPDK. However it is still too complicated. I am breaking it down to three BPs. 03:45:55 1. build PCI resource data model. I am almost done with the design spec. Should have it ready for review tomorrow. 03:46:23 2. Support PciPassthroughFilter in zun scheduler 03:47:10 3. Support SR-IOV usage. It has dependency on Kuryr. 03:47:38 #link https://blueprints.launchpad.net/zun/+spec/support-pcipassthroughfilter 03:47:46 lakerzhou: Hi, what dependency we have on kuryr for SR-IOV 03:47:48 Once I have #1 reviewed. I will finalize #3. 03:48:17 lakerzhou: ack 03:48:34 lakerzhou: i couldn't find hte bp for #3, do you have the link? 03:48:50 lakerzhou: I can help you if you need help on NFV side as I am working closely with OpenStack NFV orchestration team 03:49:20 two major changes in Kuryr. 1. matching a SR-IOV port to endpoint; 2. Binding endpoint to container 03:49:39 okay 03:50:25 Hongbin, I don't have a BP for #3 yet 03:50:49 lakerzhou: ack, mind i assigning you an action item to create a bp for #3? 03:51:06 Hongbin: sure, please. 03:51:25 #action lakerzhou create a bp for supporting SR-IOV usage 03:51:46 lakerzhou: i will review the action item in the next team meeting 03:52:01 lakerzhou: just fyi 03:52:29 Also, with #1 and #2 completed, we should in better position to support GPU in ZUN. 03:52:52 sound good 03:53:18 I am working with a large cloud operator with some requirements for GPU work load. 03:53:55 i see, it looks containerized gpu is a trend 03:54:14 I will share the thoughts later. But some example in spec already use GPU as a example. 03:54:28 Yeah, so many consumers are asking about containerized GPUs 03:54:47 i see 03:54:59 mostly telcos 03:55:24 that is all from me. Will send the spec of #1 for review tomorrow. 03:55:43 lakerzhou: thanks lakerzhou 03:55:44 Good work lakerzhou 03:56:05 #topic Open Discussion 03:56:22 anyone has a topic to bring up? 03:56:50 hongbin: about cinder integration, yesterday I made the setup ready, will test the patch & push it today 03:57:05 diga: ack 03:57:20 hongbin: will talk to you later as I have some questions on it 03:57:37 diga: ok 03:58:11 anything else to discuss? 03:58:38 seems no 03:58:48 all, thanks for joining the meeting 03:58:51 #endmeeting