03:00:08 <hongbin> #startmeeting zun
03:00:09 <openstack> Meeting started Tue Apr 18 03:00:08 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:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:13 <openstack> The meeting name has been set to 'zun'
03:00:14 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-04-18_0300_UTC Today's agenda
03:00:18 <hongbin> #topic Roll Call
03:00:25 <kevinz> kevinz
03:00:32 <shubhams> Shubham
03:00:41 <mkrai> Madhuri Kumari
03:00:46 * eliqiao eli lurk
03:00:47 <FengShengqin> FengShengqin
03:01:10 <hongbin> thanks for joining kevinz shubhams mkrai eliqiao FengShengqin
03:01:14 <shu-mutou> Shu Muto
03:01:26 <hongbin> thanks for joining shu-mutou
03:01:26 <lakerzhou> lakerzhou
03:01:39 <hongbin> lakerzhou: thanks for joining
03:01:44 <hongbin> ok, let's get started
03:01:49 <hongbin> #topic Announcements
03:01:51 <diga> o/
03:01:56 <hongbin> 1. We will have a "Boston Summit" release by the end of April
03:02:11 <hongbin> there are several patches i want to include in this release
03:02:22 <hongbin> 1. the interactive execute feature
03:02:30 <hongbin> #link https://review.openstack.org/#/c/445234/
03:02:47 <hongbin> 2. the kuryr integration patch
03:02:54 <hongbin> #linkhttps://review.openstack.org/#/c/453387/
03:03:14 <hongbin> would appreciate reviews on those two patches (although they are both big patches)
03:03:37 <hongbin> anything else that you want to be included?
03:03:44 <mkrai> hongbin: can we get through all the patches for kuryr integration?
03:03:53 <diga> we can include cinder-integration patch also
03:04:25 <hongbin> mkrai: this is the kuryr integration patch: https://review.openstack.org/#/c/453387/
03:04:30 <pksingh> Hello All
03:04:43 <hongbin> pksingh: hey, welcome back
03:04:56 <pksingh> :)
03:05:05 <hongbin> mkrai: from my point of view, merge this patch would be good enough: https://review.openstack.org/#/c/453387/
03:05:22 <mkrai> hongbin: I see, will review it
03:05:37 <hongbin> mkrai: there should be a few network api patches that are optional IMO
03:05:51 <hongbin> mkrai: and i rely on you for the network api design :)
03:06:35 <mkrai> Sure will start working on it
03:06:35 <hongbin> diga: for the cinder integration, we can include it if it can make it before the release
03:07:09 <diga> hongbin: yeah, I need your time to bypass the gate, let me know so that we can work on it
03:07:11 <hongbin> mkrai: thanks
03:07:22 <diga> hongbin: may be today/tomorrow, anytime
03:07:29 <mkrai> +1 for cinder integration if we can make it
03:07:40 <hongbin> diga: sure, i will help you for that
03:08:27 <hongbin> ok, any other announccement from you guys?
03:08:50 <hongbin> ok, advance topic
03:08:51 <diga> hongbin: thank you
03:08:55 <hongbin> #topic Review Action Items
03:09:02 <hongbin> 1. Hongbin help diga to get the cinder integration patch passed the gate (PENDING)
03:09:06 <hongbin> #link https://review.openstack.org/#/c/429943/
03:09:23 <hongbin> #action hongbin help diga to get the cinder integration patch passed the gate
03:09:43 <hongbin> will do that this week
03:09:47 <hongbin> 2. Everyone review the zun ui ehterpad
03:09:52 <hongbin> #link https://etherpad.openstack.org/p/pike-zun-ui
03:09:53 <diga> hongbin: I will update the PS in sometime, so that we can work gate job process
03:10:09 <hongbin> do everyone have a chance to look at the etherpad?
03:10:19 <hongbin> diga: ack
03:10:56 <pksingh> looking the etherpad
03:10:59 <mkrai> Looking at it now
03:11:10 <hongbin> ok, let's pause for a minute
03:11:50 <hongbin> thanks shu-mutou for fixing the two high priority item
03:12:15 <shu-mutou> sure!
03:12:17 <hongbin> i will figure out how to fix the third one
03:13:05 <mkrai> shu-mutou: after we support the image panel, will it show up the available images in drop down menu?
03:13:52 <shu-mutou> mkrai: yes.
03:14:03 <mkrai> Ok
03:14:21 <mkrai> Rest looks good to me. Thanks shu-mutou
03:14:24 <pksingh> i need to install latest UI in my devstack
03:14:36 <hongbin> ok, are everyone happy with the list in the etherpad
03:14:47 <shu-mutou> thanks everyone!
03:14:48 <pksingh> +1
03:14:54 <mkrai> +1
03:15:01 <shubhams> +!
03:15:04 <shubhams> +1
03:15:07 <hongbin> ok
03:15:41 <hongbin> seems the etherpad is good for everyone
03:15:50 <diga> +1
03:15:51 <hongbin> 3. Shunli created a bp for descriping anti-infinity scheduling use cases (DONE)
03:15:57 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/container-anti-affinity-policy
03:16:07 <hongbin> that conclude the action items
03:16:23 <hongbin> #topic Cinder integration (diga)
03:16:28 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/cinder-zun-integration The BP
03:16:42 <hongbin> diga: seems we already talk about this bp, anything else you want to add?
03:16:57 <diga> nothing from my side
03:17:03 <hongbin> ok
03:17:13 <hongbin> then, let's advance topic
03:17:23 <hongbin> #topic Kuryr integration (hongbin)
03:17:27 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/kuryr-integration The BP
03:17:41 <hongbin> here is the first patch: https://review.openstack.org/#/c/453387/
03:17:44 <hongbin> #link https://review.openstack.org/#/c/453387/
03:17:58 <hongbin> this patch is big, let me explain what it does
03:18:30 <hongbin> basically, when a user create a container, this patch will try to find an available neutron network (i.e. private)
03:18:52 <hongbin> then, find its subnets/gateway/cidr etc
03:19:28 <hongbin> use all the information to compile a list of parameter for a api call to docker to create a docker network
03:20:09 <hongbin> when the container is joining the network, zun will create a neutron port
03:20:31 <hongbin> then, pass the ip address of the port on the container creation
03:20:56 <hongbin> as a result, kuryr will pick up the pre-created neutron port and plug the container to it
03:21:19 <hongbin> so far, everything is done in the backgroup, the api is the same as before
03:21:49 <hongbin> in the future, we might need an option to specify the neutron network to create the container (right now, it is auto-select)
03:22:20 <hongbin> then, it might need a network api to manage the created docker network
03:22:41 <hongbin> however, that is optional for the demo in boston summit
03:23:10 <hongbin> that is everything from my side
03:23:13 <hongbin> questions?
03:23:37 <pksingh> hongbin, so each container may be created in different network?
03:24:07 <mkrai> How is the private network selected in case of multiple network?
03:24:09 <hongbin> pksingh: it will be created in the same network if they are in the same tenant
03:24:44 <pksingh> ok, my next question would be same as mkrai :)
03:24:59 <hongbin> mkrai: it will choose the first available network
03:25:11 <hongbin> the logic is in the method: _get_available_network
03:25:50 <hongbin> at here: https://review.openstack.org/#/c/453387/9/zun/container/docker/driver.py , line #500
03:26:20 <hongbin> the chosen network don't have to be 'private'
03:26:33 <hongbin> however, it will be a usable network
03:26:54 <hongbin> (the network selection logic was copied from nova)
03:27:12 <hongbin> however, it would be nice if there is an option to select the network
03:27:24 <hongbin> which is a future work
03:27:25 <mkrai> Then we would end up to land all the containers in only one network
03:27:32 <mkrai> Yes I also think so
03:27:52 <hongbin> mkrai: yes, if auto-select, all containers will be on the same network
03:28:02 <pksingh> nets[0] would be same for all containers?
03:28:21 <hongbin> pksingh: what is nets[0]?
03:28:23 <pksingh> what if some networrks are added?
03:28:38 <pksingh> line #507  in same file
03:29:04 <mkrai> that is the first available network as you said
03:29:22 <hongbin> pksingh: i see, if some networks are added, it might pick another network
03:29:44 <hongbin> it just pick the first network at the time the container is created
03:30:34 <pksingh> so it may be different for different containers, do we need to fix it or it is not necessary as of now?
03:31:11 <diga> pksingh: we can keep same network for host containers
03:31:36 <hongbin> i think the fix would be adding an option like "zun run --net=xxx nginx ..."
03:31:47 <diga> yeah
03:32:02 <pksingh> for time being in auto select can we sort by creation time?
03:32:15 <eliqiao> hongbin: what if the container have more than 1 nics/network?
03:32:24 <hongbin> pksingh: yes, that is an option
03:32:40 <hongbin> pksingh: however, the first created network will be deleted later
03:32:52 <hongbin> pksingh: so there is no way to pick the same network as before
03:33:19 <pksingh> ok
03:33:25 <shu-mutou> hongbin: does it not use kuryr for now?
03:33:32 <hongbin> eliqiao: right now, container can have only 1 nic
03:33:42 <eliqiao> ok.
03:33:47 <hongbin> eliqiao: containers with multiple nics is future work
03:33:57 <eliqiao> good to know, thx hongbin
03:34:13 <hongbin> shu-mutou: it use kuryr as a docker network driver
03:34:41 <pksingh> hongbin: will look into PS today, will put my thoughts there
03:34:51 <hongbin> pksingh: thx
03:35:11 <mkrai> hongbin: Also do we go and use the next available network, if we have used up all the ips in one network?
03:35:12 <shu-mutou> do you mean that available nets are using kuryr?
03:35:46 <hongbin> mkrai: that might be a good idea, i would leave it as future work
03:36:10 <mkrai> hongbin: Ok
03:36:29 <hongbin> shu-mutou: the available net is a neutron net
03:37:00 <hongbin> shu-mutou: however, zun passes it to docker and docker calls kuryr-libnetwork to create the container network
03:37:02 <shu-mutou> hongbin: are they bridged to kuryr nets?
03:37:26 <hongbin> shu-mutou: kuryr doesn't have network
03:37:34 <hongbin> shu-mutou: i guess you mean docker net?
03:37:55 <shu-mutou> ah, yes. created by kuryr.
03:37:56 <hongbin> shu-mutou: docker-net is basically a wrapper of neutron net (if powered by kuryr)
03:38:40 <hongbin> from end-users point of view, they only see the neutron network
03:38:48 <hongbin> docker network is somehow internal to zun
03:39:09 <hongbin> ok, we need to advance topic for new
03:39:11 <hongbin> now
03:39:23 <shu-mutou> hongbin: thanks. I'll be proceeding more to investigate kuryr.
03:39:29 <hongbin> please leave your comments in the review if you have further question
03:39:36 <hongbin> shu-mutou: ack
03:39:41 <hongbin> #topic Introduce container composition
03:39:47 <hongbin> #link https://review.openstack.org/#/c/437759/
03:39:54 <hongbin> kevinz: ^^
03:40:12 <kevinz> Hi all
03:40:51 <kevinz> I've upload all the info (about capsule yaml format, API) to this spec.
03:41:29 <kevinz> So it will be great if you can give a review about this :-)
03:41:53 <kevinz> The capsule format is mostly like Pod in K8s.
03:43:04 <hongbin> yes, the sample yaml file explains the format very well
03:43:14 <hongbin> i like that
03:43:34 <pksingh> kevinz: i will try to review by today
03:43:47 <kevinz> pksingh: Thx a lot
03:43:51 <hongbin> yes, another big patch to review, i could imagine zun cores will be very busy these weeks :)
03:44:25 <mkrai> :)
03:44:31 <kevinz> HaHa
03:44:41 <hongbin> ok, any further question about bp ?
03:45:21 <hongbin> ok, next topic
03:45:28 <hongbin> #topic Reset the state of container
03:45:33 <hongbin> #link https://review.openstack.org/#/c/456172/
03:45:53 <hongbin> i am not sure about this one, want to bring it up to discuss
03:46:11 <pksingh> i looked into the issue,
03:46:17 <hongbin> basically, this patch proposed a command to set the state of the container directly into the db
03:46:39 <pksingh> as much i know, we can delete any container with force option?
03:46:49 <hongbin> yes
03:48:03 <hongbin> pksingh: what do you think about the idea
03:48:21 <hongbin> pksingh: good idea? bad idea?
03:48:36 <pksingh> hongbin: i was thinking now we can start/restart container in error state, and we can delete any container using force option
03:48:50 <pksingh> hongbin: i think its not necessary
03:48:56 <hongbin> pksingh: ack
03:49:10 <hongbin> mkrai: kevinz what do you think?
03:49:15 <mkrai> hongbin: this sets the state to ?
03:49:31 <mkrai> I didn't get the use case properly
03:49:55 <hongbin> basically, this command can set the container to any state
03:49:57 <mkrai> I need to look into the spec and will post my thoughts there
03:50:05 <hongbin> ok
03:50:24 <hongbin> then, let's table this one
03:50:26 <kevinz> hongbin: if just set status in db, I think I agree with pksingh
03:50:36 <hongbin> kevinz: ack
03:51:03 <hongbin> ok
03:51:12 <pksingh> hongbin: why PAUSED state is not there in force delete https://github.com/openstack/zun/blob/master/zun/common/utils.py#L40
03:51:19 <pksingh> any specific reasons
03:51:27 <hongbin> pksingh: because docker doesn't allow it
03:51:36 <pksingh> hongbin: ok
03:52:21 <mkrai> From the discussion, it seems it is not making much sense
03:52:55 <hongbin> ok, then i will comment on the patch about that
03:53:12 <hongbin> i am not sure why nova has the reset-state command
03:53:47 <pksingh> hongbin: may we can ask from them and then we take action on our patch
03:54:09 <hongbin> pksingh: sure
03:54:25 <hongbin> i will ask the nova core i know
03:54:47 <pksingh> hongbin: that would be great :)
03:54:58 <hongbin> #topic Open Discussion
03:55:16 <FengShengqin> https://bugs.launchpad.net/zun/+bug/1682011
03:55:18 <openstack> Launchpad bug 1682011 in Zun "Check the status of sandbox container" [Undecided,New] - Assigned to <email address hidden> (feng-shengqin)
03:55:19 <hongbin> all, any other topic that needs a team discussion?
03:56:12 <hongbin> FengShengqin: reading the bug
03:56:35 <FengShengqin> need  check sandbox when check the state of container?
03:58:09 <hongbin> this is odd
03:58:26 <hongbin> if the sandbox is stopped, the real container is supposed to be stopped
03:58:41 <hongbin> no idea why it still alive
03:59:11 <hongbin> anyway
03:59:47 <hongbin> FengShengqin: i need to give it more thoughts
04:00:05 <hongbin> FengShengqin: let's continue the discussion at openstack-zun channel
04:00:07 <FengShengqin> OK
04:00:09 <hongbin> all, thanks for joining
04:00:15 <hongbin> see you
04:00:18 <hongbin> #endmeeting