03:00:02 <hongbin> #startmeeting zun
03:00:03 <openstack> Meeting started Tue Jun 13 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:06 <openstack> The meeting name has been set to 'zun'
03:00:07 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-06-13_0300_UTC Today's agenda
03:00:13 <hongbin> #topic Roll Call
03:00:17 <Namrata> Namrata
03:00:24 <kevinz> kevinz
03:01:39 <hongbin> thanks for joining the meeting Namrata kevinz
03:01:51 <hongbin> will pause for a few more minutes for potential attendees
03:02:02 <Namrata> yeah sure
03:02:22 <mkrai> Madhuri
03:02:36 <mkrai> SOrry I am late
03:02:40 <hongbin> hi mkrai
03:02:42 <hongbin> np
03:02:51 <lakerzhou> Sorry, I am late
03:03:04 <hongbin> hi lakerzhou , np at all
03:03:10 <hongbin> ok, let's get started
03:03:17 <hongbin> #topic Announcements
03:03:33 <hongbin> i have no announcement
03:03:40 <mkrai> I have one
03:03:46 <hongbin> mkrai: go ahead
03:04:00 <mkrai> Clear container runs very  well with Zun. I have tested
03:04:10 <hongbin> great!!!
03:04:27 <kevinz_> good news
03:04:28 <mkrai> So I am waiting for my patch to be merged in docker-py
03:04:41 <Namrata> mkrai great work !!
03:04:42 <lakerzhou> mkrai, great news! I planed to try it. Can you share your notes?
03:04:55 <mkrai> So we are good to support clear container in zun
03:05:01 <mkrai> lakerzhou: Yes I will do that
03:05:10 <mkrai> Thank you everyone :)
03:05:22 <mkrai> That's all from my side.
03:05:32 <hongbin> this is a great new, thanks mkrai
03:05:51 <mkrai> My pleasure :)
03:05:55 <hongbin> any other announcement from other?
03:06:14 <hongbin> seems no
03:06:17 <hongbin> #topic Cinder integration
03:06:22 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/direct-cinder-integration Direct Cinder integration
03:06:27 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/cinder-zun-integration Cinder integration via Fuxi
03:06:43 <hongbin> i have the spec up for review for the direct cinder integration
03:06:57 <hongbin> #link https://review.openstack.org/#/c/468658/
03:07:15 <hongbin> would like your comment on the idea
03:07:23 <hongbin> for example, it is a good idea? bad idea
03:07:39 <hongbin> in addition, i am working on a WIP patch
03:07:56 <mkrai> Ok I will review the spec today. Sorry was not able to see due to some other work.
03:08:03 <hongbin> hopefully, will get it done next week, so that you could see what will be implemented
03:08:13 <hongbin> mkrai: np at all, take your time
03:08:43 <kevinz_> the same to me. I will review the spec this week:-)
03:09:01 <hongbin> for recap, this bp is for operators who want to try zun service, but don't want the overhead to install yet another serivice (fuxi), so i proposed this idea
03:09:50 <mkrai> Ok I think I am confused
03:10:05 <mkrai> hongbin: there is one with direct fuxi also. Right?
03:10:22 <hongbin> mkrai: there will be two volume driver: fuxi, cinder
03:10:56 <hongbin> mkrai: cinder is not a service, it is a self-contained driver in zun tree
03:11:00 <mkrai> And which one is the above spec?
03:11:07 <hongbin> mkrai: fuxi is a docker remote plugin for volume
03:11:26 <hongbin> mkrai: i modified the existing spec to clarify that there will be two drivers
03:11:35 <mkrai> so that driver calls Cinder for volume?
03:11:36 <hongbin> mkrai: so the spec is for both
03:11:45 <hongbin> mkrai: yes
03:12:08 <mkrai> ok and in fuxi driver we directly call Fuxi?
03:12:16 <hongbin> mkrai: and i believe diga will work on another driver for fuxi, these will be a parallel effort
03:12:36 <hongbin> for fuxi driver, will call docker (i.e. docker volume create --driver fuxi ...)
03:13:10 <mkrai> ok got it. Thanks.
03:13:19 <hongbin> np
03:13:39 <hongbin> hope everything is clear, feel free to ask for clarification if there is anything is not clear
03:14:26 <hongbin> ok, i will leave everything to comment on the reviews offline
03:14:34 <hongbin> next topic
03:14:36 <hongbin> #topic Introduce container composition (kevinz)
03:14:41 <hongbin> #link https://review.openstack.org/#/c/437759/ The design spec
03:14:45 <hongbin> #link https://etherpad.openstack.org/p/zun-container-composition The etherpad
03:14:48 <hongbin> kevinz: ^^
03:15:13 <kevinz_> Hi hongbin
03:15:31 <hongbin> kevinz_: hey, want to drive this topic?
03:15:47 <kevinz_> Last week the spec has been merged, thanks every one's comments
03:15:53 <kevinz_> hongbin: of course
03:16:19 <kevinz_> kevinz_: I have a simple plan for the next step
03:17:01 <kevinz_> Maybe the first milestone in WIP patch: 1. Python-zunclient abstract the useful yaml file, send it to zun-api
03:17:12 <kevinz_> 2. Zun-api store the information to database
03:17:20 <kevinz_> 3. Zun-api call zun-compute, create containers inside one sandbox
03:17:51 <hongbin> sounds good to me
03:17:58 <kevinz_> immature plan, need for your comments:-)
03:18:06 <kevinz_> hongbin: aha, it's good
03:18:07 <mkrai> kevinz_: I have one question
03:18:14 <kevinz_> mkrai: go ahead
03:18:31 <mkrai> Should we leave the yaml abstraction to zunclient?
03:18:48 <mkrai> Because eventually these clients will be deprecated from OpemStack
03:19:40 <kevinz_> mkrai: Now plan to leave it in zunclient. But every thing we can discuss
03:20:03 <mkrai> I think it's better to do this server side itseld
03:20:08 <mkrai> *itself
03:20:28 <mkrai> Others, what do you think about this?
03:20:57 <kevinz_> mkrai: so that the client need to do is just send the yaml to server?
03:21:07 <mkrai> yes
03:22:04 <hongbin> for me, it is hard to tell which one is better for now
03:22:59 <mkrai> the python clients are optional to any project.
03:22:59 <kevinz_> I will do some investigation of K8s, whether the yaml abstraction is in kubectl or kube-api
03:23:00 <lakerzhou> I vote to implement the ymal processing in server. So less overall implementation work.
03:23:18 <mkrai> It depends on the users/operator how they want to use the service.
03:23:40 <mkrai> So that's why its always good to include all the task in server side. That's my 2 cents :)
03:24:05 <mkrai> kevinz_: sure
03:24:24 <hongbin> yes, i agree that this is the approach taken by most of the openstack projects (do heavy lifting in server side)
03:24:45 <hongbin> it seems like a valid arguement
03:25:05 <hongbin> but i will leave it to kevinz to decide
03:25:49 <kevinz_> hongbin: OK, I will do some DI first before implementation
03:26:03 <hongbin> kevinz_: thx
03:26:15 <hongbin> any more comments on this topic?
03:26:20 <kevinz_> my pleasure
03:26:32 <kevinz_> No more now, until the persist DB
03:26:46 <kevinz_> persist infra container in DB
03:26:56 <hongbin> yes, that would be the next topic
03:27:02 <kevinz_> good
03:27:05 <hongbin> #topic Persist infra container in DB
03:27:09 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/infra-container-in-db
03:27:25 <hongbin> the discussion is in a review, let me find it
03:27:39 <hongbin> #link https://review.openstack.org/#/c/467535/
03:28:25 <hongbin> the discussion is about the design of the data model
03:28:40 <hongbin> there are two options listed in the whiteboard of hte BP
03:29:14 <hongbin> option 1: treat infra container as a normal container and store it in the "container" table
03:29:41 <hongbin> option 2: treat infra container as special and store it in a separated table (called sandbox)
03:30:15 <hongbin> option 3: treat infra container as part of the capsule, and store it in a "capsule" related table
03:30:55 <mkrai> hongbin: I remember in last discussion, question was what all information is saved for this infra container
03:30:55 <hongbin> i remembered mkrai perference is option 1 if the data model of these two objects are similar
03:31:15 <hongbin> kevinz perference is option 3
03:31:17 <mkrai> If we know the fields then answering this question would be simpleter
03:31:38 <mkrai> hongbin: Yes it depends on the info which we want to store
03:32:26 <mkrai> Option #3 also sounds reasonable but have some implications
03:32:27 <hongbin> #link https://review.openstack.org/#/c/467535/5/zun/db/sqlalchemy/alembic/versions/4975f1a450ee_init_infra_container_table.py
03:32:29 <kevinz_> If we "really" plan to use "capsule" to replace "sanbox", I think option 3 is the minimum cost
03:32:44 <hongbin> it looks shengqin copy all hte fields
03:33:24 <mkrai> hongbin: yes it seems it is same as contaienr table
03:33:30 <mkrai> I think we don't want to do that
03:33:32 <lakerzhou> I like option 3 more because it should always go together with capsule I think. Then why not model them together.
03:34:24 <hongbin> lakerzhou: ack
03:34:45 <mkrai> i think both option 1 and 3 depending on we create single container or a capsule respectively.
03:34:55 <kevinz_> If not plan to use "capsule" to replace "sanbox", leave capsule and sandbox separately would be better
03:35:18 <hongbin> kevinz_: i think "capsule" will replace "sandbox" :)
03:35:43 <kevinz_> hongbin: Haha, thx
03:35:47 <hongbin> kevinz_: so option 2 is basically out
03:36:03 <mkrai> hongbin: if that's the case, I vote option #3
03:36:21 <hongbin> mkrai: ack
03:36:44 <hongbin> kevinz_: one last thing from me is that k8s has designed their data model for pod
03:37:00 <hongbin> kevinz_: which might be similar to our use cases (capsule)
03:37:22 <hongbin> we could take a bit of time to look into the data model of k8s and evaluate it
03:37:34 <kevinz_> hongbin: yes. I think this is the first thing I need to do
03:38:34 <hongbin> mkrai: lakerzhou you have further remark on this one?
03:38:57 <mkrai> No that's all.
03:39:02 <kevinz_> hongbin: the rudiment for data model is in the spec. I will implement in the code
03:39:06 <lakerzhou> no, I don't. don't re-invent the wheel for sure.
03:39:26 <hongbin> ack
03:39:59 <hongbin> ok, seems it is time to move to the next topic
03:40:27 <hongbin> i wanted to bring up the heat topic, but Namrata just said that she needed to leave
03:40:50 <hongbin> fyi, she uploaded a revision on the heat side
03:41:04 <hongbin> #link https://review.openstack.org/#/c/437810/
03:41:26 <hongbin> it needs further improvement but it looks quite close
03:41:42 <mkrai> Great!
03:41:50 <hongbin> ok, then i am going to bring up the discussion of hte nfv
03:42:02 <hongbin> #topic NFV use cases
03:42:08 <hongbin> #link https://etherpad.openstack.org/p/zun-nfv-use-cases
03:42:18 <hongbin> lakerzhou: want to drive this one ?
03:42:59 <hongbin> lakerzhou: wow, i saw you added a lot of content on the etherpad, need to catch it up :)
03:44:14 <hongbin> lakerzhou: you have anything want to discuss about the nfv use cases?
03:44:45 <lakerzhou> Sorry, last seconds of NBA final
03:44:51 <hongbin> :)
03:44:56 <kevinz_> haha
03:44:58 <mkrai> :D
03:45:01 <hongbin> ok, we could leave it as a homework
03:45:09 <hongbin> then, end the meeting now
03:45:23 <hongbin> all, thanks for joining, enjoy the nba final :)
03:45:28 <lakerzhou> I need more time for the spec, had good discussion with Hongbin
03:45:29 <mkrai> hongbin:one thing
03:45:39 <hongbin> mkrai: go ahead
03:45:43 <mkrai> Do you think we should add the api-ref gate?
03:46:00 <hongbin> mkrai: i think we should
03:46:14 <mkrai> Ok thanks
03:46:17 <mkrai> I will do that
03:46:25 <hongbin> mkrai: thx
03:46:39 <kevinz_> thx mkrai:-)
03:46:48 <kevinz_> btw, I will go to Beijing for OPNFV summit this week. Hope to collect some user case for zun
03:46:55 <lakerzhou> Hongbin, I will update the NFV use cases more, and submit a spec with SR-IOV use case by the end of this week
03:47:01 <mkrai> kevinz_: cool
03:47:02 <hongbin> kevinz_: that would be great
03:47:17 <hongbin> lakerzhou: sounds great
03:47:48 <hongbin> all, thanks for joining, have a good day
03:47:51 <hongbin> #endmeeting