03:00:09 <hongbin> #startmeeting zun
03:00:10 <openstack> Meeting started Tue Aug  8 03:00:09 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:11 <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:16 <hongbin> #link https://wiki.openstack.org/wiki/Zun Today's agenda
03:00:17 <mkrai> Madhuri
03:00:20 <hongbin> #topic Roll Call
03:00:25 <Namrata> Namrata
03:00:26 <pksingh> Hello
03:00:30 <kiseok7> hello
03:00:31 <spn> o/
03:00:58 <kevinz> kevinz
03:01:15 <hongbin> thanks for joining hte meeting mkrai Namrata pksingh kiseok7 spn kevinz
03:01:22 <kiennt> o/
03:01:25 <hongbin> let's get started
03:01:31 <hongbin> thanks for joining kiennt
03:01:36 <hongbin> #topic Announcements
03:01:42 <hongbin> 1. We will cut a pike release for Zun server soon (within one week or two)
03:01:50 <hongbin> #link https://releases.openstack.org/pike/schedule.html Pike release schedule
03:02:29 <hongbin> if you have patches that need to land on pike, please submit it in these weeks
03:03:03 <hongbin> that is all from me
03:03:15 <hongbin> another announcement from our team members?
03:03:51 <hongbin> a question, which patches you think we should land on pike and haven't been merged?
03:04:10 <hongbin> #link https://review.openstack.org/#/q/project:openstack/zun the review queue
03:04:17 <shu-mutou> Hi!
03:04:24 <mkrai> I have one on "make delete async"
03:04:27 <hongbin> hi shu-mutou
03:04:32 <mkrai> I will resubmit the patch today
03:04:50 <mkrai> hongbin: This one https://review.openstack.org/#/c/452660/
03:04:50 <hongbin> mkrai: ack, this one needs an api version bump i think
03:05:05 <mkrai> hongbin: Will do it. Thanks
03:05:32 <Shunli> create with existing port is better to have in pike, i think.
03:05:44 <hongbin> Shunli: ack
03:05:57 <hongbin> #link https://review.openstack.org/#/c/481861/
03:06:07 <hongbin> anything else?
03:06:27 <hongbin> ok
03:06:45 <hongbin> reviewers, please put the above patches in a higher priority
03:06:59 <hongbin> ok, next topic
03:06:59 <pksingh> sure
03:07:02 <hongbin> #topic Review Action Items
03:07:08 <hongbin> 1. hongbin ask nova core about how to deal with api microversion (PENDING)
03:07:16 <hongbin> i will do that this week
03:07:22 <hongbin> 2. hongbin pose an architecture diagram at the zun wiki page (DONE)
03:07:29 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Architecture
03:07:42 <hongbin> that is all for review action items
03:07:59 <hongbin> any question for this topic?
03:08:17 <hongbin> #topic Cinder integration
03:08:29 <hongbin> i am working on this one
03:08:44 <hongbin> what is ready to review is a WIP patch in CLI
03:09:00 <hongbin> #link https://review.openstack.org/#/c/491271/
03:09:23 <hongbin> it is not ready to merge yet, but you could see how the CLI will look like
03:09:42 <hongbin> i am still working on the server side patch, hope i can get a WIP patch ready this week
03:10:10 <hongbin> if this feature is finish, the CLI command will look like this:
03:10:26 <hongbin> $ zun run -v <cinder_volume>:/data <image>
03:10:55 <hongbin> that means bind-mount the cinder volume to the container in '/data' path
03:11:09 <shu-mutou> Will Cinder integration be merged in Pike?
03:11:22 <hongbin> shu-mutou: no, will target on Q
03:11:33 <shu-mutou> I see. thx. :)
03:11:49 <hongbin> any other comment on this?
03:12:17 <spn> cinder_volume is a pre-allocated vol?
03:12:33 <hongbin> spn: in the first implementation, it is pre-allocated
03:13:13 <hongbin> spn: if someone else has a proposal to allocate the volume along with the container, it can go into the second iteration of implementation
03:13:25 <spn> hongbin: ok. makes sense
03:13:41 <Shunli> the CLI will be reused by fuxi driver, right?
03:14:19 <hongbin> Shunli: yes, the CLI should be independent of hte backend, regardless of fuxi or others
03:14:47 <Shunli> ack
03:15:39 <hongbin> ok, seems there is no more comment, advance topic
03:15:42 <hongbin> #topic Introduce container composition (kevinz)
03:15:49 <hongbin> kevinz: ^^
03:15:53 <kevinz> Hi All
03:16:30 <kevinz> Last week I'm blocked with some internal issues, could not do more about capsule
03:16:42 <kevinz> Just move the capsule API to experimental
03:17:00 <kevinz> Patch has submitted yesterday
03:17:14 <hongbin> kevinz: perhaps you could explain to the team why we decide to move the API to experimental
03:17:26 <kevinz> https://review.openstack.org/#/c/484602/
03:18:22 <kevinz> hongbin: yeah, because capsule API still in development, staying in API v1 will bump the version when new capsule introduce
03:19:19 <hongbin> kevinz: yes, that is the reason
03:19:31 <kevinz> So move the v1/capsules/ to experimental/capsules. So separate capsule with v1, and keep v1 stable. When capsule API are ready to merge, we can move it to v1.
03:20:38 <hongbin> any comment on this?
03:20:42 <kevinz> So now if we want to use capsules API, need to create new service and entry point for it. There is a patch about this: https://review.openstack.org/#/c/491451/
03:21:39 <mkrai> zun capsule-create will work with this?
03:22:16 <mkrai> How is it handled at the zunclient? Multiple services?
03:22:16 <kevinz> mkrai: yeah, any capsule api will work in experimental
03:23:01 <kevinz> mkrai: create a new service called: zun-experimental
03:23:27 <kevinz> mkrai: zunclient will use this.
03:23:34 <mkrai> Because the service type at zunclient is 'container'.
03:24:03 <kevinz> mkrai: yes, new service type called  container-experimental.
03:24:04 <mkrai> We might have to specify the zun-experimental explicitly.
03:24:17 <mkrai> Is there a patch for zunclient uploaded already?
03:24:44 <kevinz> mkrai: Not yet, will push it in a minute:-)
03:25:04 <kevinz> after solve some conflicts
03:25:11 <mkrai> kevinz: Ok I will look at it. Thanks :)
03:25:22 <hongbin> i think it will be similar as cinder v2 and v3, both version has an api endpoints and service catalog
03:25:23 <kevinz> mkrai: Thx very much
03:25:51 <kevinz> hongbin: definitely
03:25:57 <mkrai> hongbin: ack. I haven't seen at cinder code :)
03:26:47 <hongbin> any other comment before advancing topic?
03:27:23 <hongbin> ok, the next topic is NFV
03:27:43 <hongbin> however, lakerzhou said he cannot come today, so let's skip this one
03:27:53 <hongbin> #topic Zun connector for k8s
03:28:01 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/zun-connector-for-k8s
03:28:11 <mkrai> This one sounds interesting :)
03:28:30 <kevinz> Good topic
03:28:31 <hongbin> yes
03:28:41 <hongbin> first, let me introduce the context a bit
03:29:09 <hongbin> microsoft has annouce a new container service called Aurze Container Instance (ACI): https://azure.microsoft.com/en-us/blog/announcing-azure-container-instances/
03:29:22 <hongbin> ACI is basically a microsoft version of Zun
03:29:51 <hongbin> In ACI, the main resource is container
03:30:22 <hongbin> Users can use ACI to create/delete/update/... container
03:30:44 <hongbin> In addition, there is a k8s connector for AC
03:30:46 <hongbin> ACI
03:31:11 <hongbin> #link https://github.com/Azure/aci-connector-k8s
03:31:23 <hongbin> i haven't looked into it in deep
03:31:32 <hongbin> however, the idea looks very interesting
03:32:00 <hongbin> which i think the Zun team might borrow the idea for k8s integration
03:32:15 <hongbin> in summarize, how it works is to register a node in k8s
03:32:32 <hongbin> the node represent the ACI service, and it has unlimited cpu/memory/...
03:33:02 <hongbin> if pod is scheduled on this node, the ACI connector will translate it to a few containers in ACI
03:33:33 <hongbin> basically, it allows users to use k8s API to run containers on microsoft cloud
03:33:43 <hongbin> that is a general introduction
03:33:48 <hongbin> any question so far?
03:33:51 <pksingh> so k8s will invoke ACI connector?
03:33:52 <kevinz> So it sounds like zun will serve as a backend for k8s?
03:34:00 <hongbin> pksingh: i think yes
03:34:18 <pksingh> so similar interface as kubelet?
03:34:23 <hongbin> kevinz: yes, in particular, serve as a k8s node
03:35:20 <hongbin> pksingh: i doubt if kubelet will have any API, what kubelet does is to watch the k8s API and lauch pods
03:35:54 <kevinz> hongbin: "The whole Zun cluster" serve as a k8s node?
03:35:54 <hongbin> pksingh: however, the connector will be very similar to kubelet, i assume it will watch the k8s API for pods in a similar way
03:36:04 <pksingh> hongbin: so where does ACI fits in k8s?
03:36:21 <hongbin> kevinz: i think your interpretation is correct
03:36:28 <pksingh> ok,
03:36:58 <hongbin> pksingh: ACI is a node in k8s with unlimited compute resources
03:37:12 <pksingh> hongbin: OK
03:37:28 <mkrai> The interaction b/w k8s services and Zun is not clear I guess
03:37:46 <pksingh> i need to look more into that, will come with more questions :)
03:38:08 <mkrai> hongbin: let's create an etherpad for this?
03:38:27 <hongbin> mkrai: yes, so far, it supports pod only, how it fits into resources other than pod is unknown
03:38:35 <hongbin> mkrai: sure
03:39:11 <hongbin> #link https://etherpad.openstack.org/p/zun-connector-k8s
03:39:51 <mkrai> hongbin: Thanks
03:40:30 <hongbin> ok, we could work on the etherpad offline
03:40:41 <kevinz> That is a new integration method between OpenStack and K8S, not provision K8s, just serve k8s.
03:41:20 <hongbin> yes
03:41:21 <kevinz> Seems like kuryr-k8s, in the compute resource level
03:42:19 <hongbin> i would say zun would have a better future if we could figure out the right integration with k8s
03:42:32 <hongbin> therefore, this bp is very important
03:42:32 <mkrai> hongbin: +2
03:42:45 <Shunli> +2
03:42:56 <kevinz> +2
03:43:38 <kiennt> hongbin: that's great!
03:43:45 <hongbin> looks everyone agree on this direction
03:44:07 <hongbin> cool
03:44:15 <hongbin> any other comment on this topic?
03:44:36 <hongbin> #topic Open Discussion
03:45:35 <hongbin> if you have a topic that requires team discussion, now is the time to bring it up
03:45:42 <Shunli> I would like to start work on this bp https://blueprints.launchpad.net/zun/+spec/network-rest-api
03:45:54 <hongbin> Shunli: awesome
03:46:36 <Shunli> but docker network is on each compute node.
03:46:51 <hongbin> yes
03:46:55 <Shunli> neutron network is a global network.
03:47:29 <hongbin> therefore, i don't think it is a good idea to have a wrapper of the docker network api
03:47:40 <Shunli> seems user more likely to use a global network to create container. seems no need to implement this bp, thoughts?
03:48:17 <hongbin> in my opinion, there are at least two api is needed
03:48:23 <hongbin> 1. add_network_to_container
03:48:31 <hongbin> 2. remove_network_to_container
03:49:02 <hongbin> the network above is the global neutron network
03:49:36 <hongbin> i guess nova has a similar api to add/remove network from an instance ?
03:49:51 <hongbin> that is what i have in mind
03:50:09 <Shunli> agree. so i will change the to goal of the bp to implement attach/dettach network.
03:50:24 <mkrai> hongbin: Agree
03:51:38 <hongbin> Shunli: if you could think of any other API that is needed, please feel free to propose it
03:51:57 <Shunli> ok.
03:52:08 <hongbin> cool
03:52:33 <hongbin> any other topic to discuss?
03:52:38 <Shunli> no
03:53:24 <hongbin> ok, all, thanks for joining the meeting, see you next time
03:53:28 <hongbin> #endmeeting