03:00:04 <hongbin> #startmeeting zun
03:00:05 <openstack> Meeting started Tue Mar 21 03:00:04 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:08 <openstack> The meeting name has been set to 'zun'
03:00:11 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-03-21_0300_UTC Today's agenda
03:00:15 <hongbin> #topic Roll Call
03:00:35 <mkrai> Madhuri Kumari
03:00:36 <lakerzhou> lakerzhou
03:00:37 <shubhams> shubham
03:00:38 <Namrata> Namrata
03:01:11 <kevinz> kevinz
03:01:17 <hongbin> thanks for joining mkrai lakerzhou shubhams Namrata kevinz
03:01:21 <pksingh> pradeep
03:01:29 <hongbin> thanks for joining pksingh
03:01:36 <hongbin> let's get started
03:01:40 <zsli_> shunli
03:01:42 <hongbin> #topic Announcements
03:01:53 <hongbin> 1. Zun will have a 45 minutes on-boarding session at Boston Summit
03:01:58 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114149.html
03:02:09 <hongbin> zsli_: thanks for joining shunli
03:02:24 <hongbin> back to the topic
03:02:40 <hongbin> the on-boarding session will be provided to on-board new contributors
03:03:09 <hongbin> basically, we will send one or more team member to there and chair the session
03:03:28 <hongbin> we will introduce new contributors how to contribute to zun project
03:04:03 <mkrai> hongbin: This is happening for the first time in summit, right?
03:04:03 <hongbin> i guess it will cover how to run tests, how this component is going to work, etc.
03:04:13 <hongbin> mkrai: yes, it is the first time
03:04:40 <hongbin> if anyone want to chair this session, please feel free to let me know, otherwise, i can be the default chair
03:05:16 <hongbin> any other question about this?
03:05:39 <hongbin> if not, hope to see you all there
03:05:50 <hongbin> #topic Cinder integration (diga)
03:05:56 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/cinder-zun-integration The BP
03:06:11 <hongbin> diga sent me an email saying that he cannot attend
03:06:17 <hongbin> here is the update he sent me
03:06:24 <hongbin> I have resolved fuxi/docker issue and things are working for me at last.
03:06:30 <hongbin> API level integration with Cinder & Docker is completed
03:06:35 <hongbin> Will upload latest patch with test cases as it is failing CI jobs.
03:06:43 <hongbin> That is all from him
03:06:49 <hongbin> any comment about this bp?
03:07:41 <hongbin> ok, move on
03:07:44 <hongbin> #topic Kuryr integration (hongbin)
03:07:50 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/kuryr-integration The BP
03:08:12 <hongbin> at last week, most of the patches i submitted to kuryr-libnetwork got merged
03:08:30 <hongbin> based on how the patches were merged, i submitted a revision to the spec
03:08:41 <hongbin> #link https://review.openstack.org/#/c/447732/
03:08:51 <hongbin> here is the general idea
03:09:31 <hongbin> to create a network, users are expected to pass an existing neutron net to zun
03:09:56 <hongbin> for example, it could be a "private" net pre-created by most of hte cloud
03:10:38 <hongbin> when a user request to create a container, zun will use user's token to create a port from private net
03:11:04 <hongbin> then, zun will figure out all the information from the port, e.g. the subnetpool id, the cidr, the gateway, etc.
03:11:31 <hongbin> this information will pass to kuryr to create the network and configure the network of hte container
03:11:58 <hongbin> in general, the behaviour should be similar to nova (user create vm by specifying a neutron net)
03:12:15 <mkrai> So do we need the network API now?
03:12:23 <hongbin> mkrai: yes
03:12:43 <mkrai> I see it is just storing the info in db
03:12:45 <hongbin> mkrai: however, the network api would be just a wrapper of a neutron network at the first iteration
03:12:59 <mkrai> And what else is the thing can be done by the API?
03:13:24 <hongbin> i guess nothing else at the first iteration
03:13:42 <hongbin> later, we might store additonal information, such labels, subnet, etc.
03:14:28 <mkrai> Ok I will try to review the spec and provide my input if any
03:14:40 <hongbin> mkrai: ack, thx
03:14:46 <mkrai> hongbin: Thanks for your great effort on this
03:15:11 <pksingh> hongbin: is it necessary to provide the API to store information in DB?
03:15:27 <kevinz> hongbin: thanks hongbin, great work
03:15:33 <pksingh> hongbin: cant we do it during container create?
03:16:06 <hongbin> pksingh: i think the answer is yes
03:16:36 <hongbin> i guess there would be benefits for two container to connect to the same "container network"
03:17:11 <hongbin> e.g. two containers can discover each other if they are in the same docker network
03:17:16 <pksingh> hongbin: i see,
03:17:56 <hongbin> however, we could provide a short cut version for users to allow them to bypass the network api
03:18:11 <hongbin> this could directly create container from neutron net
03:18:21 <pksingh> hongbin: we store the network infor just for multitenancy?
03:19:01 <hongbin> pksingh: i think it is more than that
03:19:25 <hongbin> pksingh: a network in zun is basically represents a docker network if driver is docker
03:20:03 <pksingh> hongbin: OK, thanks for explaining, will look into the spec and put my queries there
03:20:20 <hongbin> pksingh: sure
03:20:58 <hongbin> more comments?
03:21:29 <hongbin> ok, advance topic
03:21:31 <hongbin> #topic Introduce host capabilities and cpusets (sudipto)
03:21:37 <hongbin> #link https://review.openstack.org/#/c/427007/ The spec
03:21:49 <hongbin> it looks sudipta is not here
03:22:09 <hongbin> we could skip this one unless anyone want to comment on this topic
03:22:45 <hongbin> ok, next topic
03:22:51 <hongbin> #topic Introduce container composition
03:22:56 <hongbin> #link https://review.openstack.org/#/c/437759/
03:22:59 <hongbin> kevinz: ^^
03:23:38 <kevinz> Hi all, I've uploaded a net version of the spec
03:24:31 <kevinz> Add the implementation procedure of this
03:25:21 <kevinz> also I have a proposal of the data model. http://kevinzhao.org/2017/03/18/zun-capsule-object.html   hope your feedback of this
03:27:23 <pksingh> kevinz: i am not able to open the link in office, may be i will check this at home
03:28:04 <kevinz> Sorry, I have move the link to etherpad: https://etherpad.openstack.org/p/zun-container-composition
03:28:13 <kevinz> that will be easy to discuess
03:28:29 <pksingh> kevinz: thanks, it better
03:28:56 <hongbin> thanks kevinz for moving it to etherpad
03:29:10 <kevinz> yw :-)
03:29:12 <hongbin> i guess i will give everyone a few minutes to comment on the etherpad
03:29:52 <kevinz> Yeah, Also I have three question inline to discuss in the v1.CapsuleElement
03:31:21 <pksingh> i think we need to make a naming convention and at all places we should use capsule
03:33:00 <kevinz> yes sure
03:33:05 <mkrai> I wonder how we will manage both capsule container and our docker/nova-docker containers at same time
03:34:09 <mkrai> kevinz: This implementation will be a new driver for container_driver?
03:34:32 <kevinz> mkrai: Now I prefer to reuse the container driver
03:34:33 <hongbin> i guess it is a new api instead of a new driver
03:34:52 <mkrai> Yes I agree for new API
03:34:59 <pksingh> kevinz: i think we dont need to expose HOST information to user
03:35:07 <mkrai> But not sure how we will manage both containers concurrently
03:35:52 <kevinz> Yeah, API server will read the yaml info from CLI, then scheduler to create the container.
03:35:56 <kevinz> to  zun compute
03:36:24 <pksingh> kevinz: may be you are storing HOST in DB only for internal use
03:36:26 <kevinz> Plan to add a new field to container Object, to show whether it is in a capsule
03:36:49 <kevinz> pksingh: Yes, for internal use. will not expose it to user
03:37:23 <mkrai> kevinz: IMO I think we should keep the container_driver and capsule implementation seperate
03:37:47 <mkrai> kevinz: Adding the capsule field to container will make the things more complex
03:37:54 <pksingh> mkrai: i think capsule is going to user container_driver internally
03:38:15 <kevinz> pksingh: Yeah just internally use it
03:38:41 <mkrai> pksingh: Yes but I don't we need to add the merge both the implementations
03:39:17 <hongbin> mkrai: basically, what we have right now is 1 infra container + 1 real container, which is basically a 1 container capsule
03:39:46 <hongbin> mkrai: i think the proposal is just an extension to support 1 infra container + multiple real containers
03:40:37 <kevinz> hongbin: +1
03:41:13 <mkrai> hongbin: thanks for explaining
03:41:15 <pksingh> point is how to make a relationship between container and capsule in DB?
03:41:34 <hongbin> pksingh: this is a good question
03:41:41 <pksingh> if we remove the container API and keep only capsule APIS then things would be easier?
03:41:52 <mkrai> Yes that is same question
03:41:52 <kevinz> That a question need to discuss
03:42:08 <mkrai> Thanks pksingh for puttng in better words :)
03:42:30 <pksingh> :)
03:42:45 <kevinz> pksingh: Yeah that will be totally like a pod
03:42:58 <hongbin> i think there are several options here
03:43:41 <hongbin> 1. make capsule as a wrapper of the infra container, and the relationship between capsule and real containers is a one-to-many relationship
03:44:23 <hongbin> for example, for a 2 container capsule, there will be 1 db entry for capsule, 2 db entry for container
03:45:00 <hongbin> 2. make capsule as a whole
03:45:34 <hongbin> then, there will be 1 db entry per capsule that is for capturing all the information (no extra db entry for contianer)
03:45:54 <hongbin> that is all i can think of
03:46:25 <pksingh> hongbin: for approach 2, what if i want the specific information for a conatiner inside the capsule?
03:46:28 <hongbin> option #2 would be more like a pod and they are stored as a unit
03:46:46 <kevinz> approach 1 has the minium change. option 2 like a pod
03:47:13 <hongbin> pksingh: i guess you need to read inside the db entry and parse information about individual containers
03:47:44 <mkrai> I think option 1 is better and preferable
03:47:55 <pksingh> hongbin: OK, so we will be storing all the information in DB for every container as blob?
03:48:14 <hongbin> pksingh: sort of ...
03:48:33 <hongbin> pksingh: perhaps it worth to discuss at the api leverl
03:48:54 <mkrai> hongbin: Right. Unify the container and capsule apis
03:48:58 <hongbin> i guess option #2 will make the api looks like a pod
03:49:34 <hongbin> zun capsule-create will create some containers, but it won't be listed by running "zun list"
03:49:38 <mkrai> the concept of container and capsule is same, so having single API layer makes much sense
03:49:59 <pksingh> I think if we use approach two, then keeping both the APIs would be more manageable
03:50:01 <hongbin> mkrai: ack
03:50:54 <pksingh> and we need to have two set of APIS, one for containers and one for capsules
03:51:24 <kevinz> pksingh: yes
03:51:36 <mkrai> pksingh: container is also a capsule but with just one container, so why do we need different api
03:51:41 <hongbin> on the other side, these two set of apis would be duplicated somehow
03:52:08 <mkrai> hongbin: Exactly
03:52:13 <pksingh> yes, thats why i said we may need to just put the capsule API only
03:52:35 <hongbin> pksingh: i believe some users prefered the simplicity of hte container api
03:53:25 <pksingh> hongbin: but then there will be lot of duplication internally
03:53:45 <mkrai> hongbin: kevinz pksingh I think the current solution could be to implement the capsule API now and see if is at all worth having 2 APIs
03:54:29 <hongbin> pksingh: i would lean to option #1 that make a capsule as a wrapper of sandbox
03:54:53 <pksingh> hongbin: then we need to have two set of APIs
03:55:05 <pksingh> hongbin: ok, got it
03:55:14 <hongbin> pksingh: yes, but they are not dupicated anymore
03:55:29 <mkrai> pksingh: Why so?
03:55:31 <hongbin> ok, let continue the dicussion at the next meeting
03:55:33 <pksingh> hongbin: ok, +1 for approach 1
03:55:36 <kevinz> I guess capsule don't need much api for operation
03:55:52 <hongbin> #topic Open Discussion
03:55:59 <hongbin> we have 5 minute left
03:56:10 <hongbin> feel free to continue the discussion until then
03:56:36 <mkrai> I also prefer option 1 but not sure why would we need two APIs
03:56:36 <pksingh> hongbin: since we are close to release, we may priortise the tasks
03:57:05 <pksingh> mkrai: as hongbin said some people want docker like APIs,
03:57:12 <mkrai> pksingh: +1
03:57:40 <hongbin> pksingh: what do you think about the priority?
03:57:56 <mkrai> pksingh: Ok I think that is a valid point. Simplicity
03:58:08 <pksingh> hongbin: i am not sure, i was thinking a MVP zun
03:58:27 <hongbin> mvp?
03:58:39 <pksingh> minimum vaiable product
03:58:53 <hongbin> ok, since mvp has many meaning :)
03:58:56 <pksingh> so i was thinking if user can use the zun for basic operation
03:59:13 <pksingh> like accessing the container from putside is still not possible
03:59:27 <hongbin> pksingh: agree
03:59:45 <hongbin> pksingh: right now, i marked the netowrk and storage bp as hte highest priority
04:00:03 <pksingh> so if we priortize the tasks then we can implement those
04:00:04 <kevinz> hongbin: +1
04:00:13 <pksingh> yse i think they are very necessary
04:00:27 <hongbin> yes
04:00:28 <hongbin> time is up
04:00:37 <hongbin> overflow on #openstack-zun channel
04:00:37 <pksingh> bye :)
04:00:41 <hongbin> #endmeeting