03:00:04 <hongbin> #startmeeting zun
03:00:05 <openstack> Meeting started Tue Nov 29 03:00:04 2016 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:09 <openstack> The meeting name has been set to 'zun'
03:00:13 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-11-29_0300_UTC Today's agenda
03:00:19 <hongbin> #topic Roll Call
03:00:21 <Namrata> Namrata
03:00:25 <kevinz> kevinz
03:00:27 <eliqiao> eliqiao
03:00:31 <shubhams> shubham
03:01:22 <lakerzhou> lakerzhou
03:02:03 <hongbin> Thanks for joining hte meeting Namrata kevinz eliqiao shubhams lakerzhou
03:02:15 <hongbin> i knew madhuri cannot come today
03:02:26 <hongbin> then, let's start
03:02:29 <sudipto_> o/
03:02:34 <hongbin> #topic Announcements
03:02:37 <hongbin> sudipto: hey
03:02:43 <hongbin> 1. Zun is applying to become an official OpenStack project
03:02:49 <hongbin> #link https://review.openstack.org/#/c/402227/
03:03:14 <hongbin> i saw most of you have casted a +1 there, which is great :)
03:03:27 <hongbin> right now, 5 tc has voted for yes
03:03:41 <hongbin> it looks everything is good so far
03:03:57 <hongbin> let's see how this application will go
03:03:58 <shubhams> hongbin: How many TC votes we need ?
03:04:14 <hongbin> shubhams: not exactly sure
03:04:22 <shubhams> hongbin: ok
03:04:30 <hongbin> shubhams: we need approval from the tc chair
03:04:34 <eliqiao> 5 are over 1/2, right?
03:04:51 <hongbin> shubhams: the tc chair will approve if there is a consensus among most of hte tc
03:04:55 <clarkb> eliqiao: no I think tc is 13 total
03:05:03 <hongbin> eliqiao: i remembered there were 13 tc
03:05:11 <clarkb> we elect 6 and then 7 for 13 total
03:05:16 <eliqiao> clarkb: oh, good to know ,thx.
03:05:35 <eliqiao> hongbin: thx :)
03:05:44 <hongbin> anything else for the big-tent application ?
03:06:08 <hongbin> ok, move on
03:06:10 <hongbin> #topic Review Action Items
03:06:13 <hongbin> none
03:06:18 <hongbin> #topic Container network (hongbin)
03:06:24 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/neutron-integration The BP
03:06:29 <hongbin> #link https://review.openstack.org/#/c/365754/ The proposed spec (merged)
03:06:34 <hongbin> #link https://review.openstack.org/#/c/396896/ The patch Part 1
03:06:39 <hongbin> #link https://review.openstack.org/#/c/399248/ The patch Part 2
03:06:53 <hongbin> right now, all the patches were merged. thanks all for reviews
03:07:11 <hongbin> i will remove this from the meeting agenda next week
03:07:32 <hongbin> before i move forward, any question for the sandbox feature?
03:07:57 <hongbin> #topic Kubernetes integration (shubhams)
03:08:02 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/k8s-integration
03:08:05 <hongbin> shubhams: ^^
03:08:19 <shubhams> We created etherpad and put down oour idea there
03:08:23 <shubhams> #link https://etherpad.openstack.org/p/zun-k8s-integration
03:09:00 <shubhams> The basic flow is : first we are trying to see if python-k8sclient can be used
03:09:24 <shubhams> and in parallel, we will finalize the APIs that we are going to introduce
03:09:37 <sudipto_> so the k8s integration is about a different set of APIs in zun?
03:09:51 <shubhams> sudipto_:  yes
03:10:12 <hongbin> let's discuss this
03:10:30 <shubhams> hongbin:  ok
03:10:35 <hongbin> right now, this is what zun currently support: container, sandbox
03:10:51 <hongbin> this is what k8s currently support: pod, service, replication controller
03:11:20 <hongbin> i think the first step is to find a reasonable overlay of the apis between zun and k8s
03:11:49 <hongbin> however, feel free to share your ideas if any
03:12:16 <kevinz> zun-api will directly talk with k8s-apiserver directly?
03:12:16 <sudipto_> Also, in this case, what are the additional features that zun would provide or will it just be a passthrough to K8s?
03:12:29 <hongbin> kevinz: i think so
03:13:02 <hongbin> sudipto_: let's cast the inputs to the etherpad
03:13:08 <eliqiao> can you tell what's your idear about zun api looks like for k8s intergration?
03:13:09 <shubhams> kevinz, hongbin : we plan to use python-k8sclient for communication between zun and k8s
03:13:25 <hongbin> shubhams: i am ok with that
03:13:43 <hongbin> shubhams: python-k8sclient will talk to kube-apiserver
03:13:46 <eliqiao> that's will bring another old magnum api problem.
03:13:49 <kevinz> OK
03:13:56 <shubhams> IMO, zun should not necessarily provide 1-to-1 mapping with k8s
03:14:03 <zhangjl> eliqiao:agree
03:14:27 <shubhams> we can have minimum set of commands for now : ex: service, pods at the minimum
03:14:36 <eliqiao> I think zun's mission is to unify container API right? (low level could be k8s docker, etc.)
03:15:12 <eliqiao> shubhams: but if your low level driver is docker, the operation will be consufsed by serice pods ...
03:15:14 <shubhams> eliqiao: right, so post k8s we can provide same features for other COEs as well , right?
03:16:26 <shubhams> zun can provide cluster  management apis in unified manner along with container management apis
03:17:05 <shubhams> What are your views on this ?
03:17:07 <eliqiao> shubhams: I don't get 'zun can provide cluster management apis'
03:17:21 <eliqiao> I think Magnum will provide that mission
03:17:44 <kevinz> zun will do just like "kubectl" do?
03:18:11 <eliqiao> If you konw the history of Magnum, Magnum support k8s/docker at sametime.
03:18:18 <shubhams> eliqiao: I am thinking in the way service and pod are managed
03:18:35 <eliqiao> it has pod/service/rc endpoint and also container endpints
03:18:40 <shubhams> kevinz: roughly speaking "yes"
03:18:55 <eliqiao> so user who using k8s will be confused by 'container'
03:19:06 <kevinz> shubhams: :D ok
03:19:22 <eliqiao> zun aimed to provide unified APIs for all COEs.
03:19:47 <Qiming> unified api for COE is different from unified API for containers ...
03:20:08 <shubhams> eliqiao: Yes. That's why we do not aim for 1-to-1 mapping with k8s
03:20:16 <hongbin> Qiming: hey, good to see you here
03:20:26 <Qiming> watching, thinking
03:20:36 <hongbin> ok, let's discuss one point
03:20:46 <hongbin> zun do not aim for 1-to-1 mapping with k8s
03:20:56 <hongbin> i agree with this point
03:21:05 <hongbin> what do you think?
03:21:09 <eliqiao> Qiming: can you detail the differences?
03:21:40 <Qiming> when we are talking about a unified API for COEs, we are aiming at a reference implementation of OCI
03:22:00 <hongbin> Qiming: You mean CNCF?
03:22:20 <Qiming> when we are talking about unified API for containers, we are abstracting away the difference between lxc, docker (minus swarm), rkt, etc.
03:22:48 <eliqiao> Qiming: yes, get it. diferent level.
03:22:57 <Qiming> we need a compelling reason for users to adopt zun
03:23:19 <Qiming> if I'm a fan of k8s, I really need a reason to switch to zun
03:24:06 <Qiming> btw, I'm not a fan of k8s yet, :D
03:24:51 <Qiming> the advantage of zun, as I see it, is it is based on OpenStack, as stated in the big-tent application
03:25:01 <Qiming> if we can maximize that value, we win
03:25:01 <shubhams> With the ongoing discussion , I get a feel that if we tend to integrate anything using (driver model eg: docker driver , k8s driver etc) then we might not be able to  acheive this goal of uniformity
03:25:30 <shubhams> As we will bounded by the limitation of features provided by respective COEs and runtimes
03:26:04 <Qiming> if we get ourselves trapped into a k8s compatibility, I'm afraid we are going nowhere
03:26:13 <shubhams> Qiming: agree
03:26:18 <hongbin> Qiming: +1
03:26:23 <sudipto_> yup!
03:26:26 <Qiming> think from users perspective
03:26:37 <Qiming> what do they need, what do they value most
03:26:52 <hongbin> i think users just want a simple API that is capable to host their applications
03:27:13 <Qiming> I share the same thought with you, hongbin
03:27:39 <hongbin> then, the zun API should start with simple and basic functionality
03:27:57 <sudipto_> Are we considering composition of services to be supported via ZUN - with the same set of docker APIs?
03:28:03 <hongbin> then, extend to an advanced set of features as we go
03:28:09 <sudipto_> docker-compose kinda functionality.
03:28:27 <Qiming> sounds like something we can leverage heat?
03:29:20 <sudipto_> I mean getting a container in openstack without real composition supported - i am not sure how useful is that.
03:29:45 <sudipto_> because we are talking about micro services and that would involve deploying a set of containers, not just one.
03:30:04 <sudipto_> The reason i brought in the conjecture is because, maybe that would help us define what we want to achieve with K8s...with zun...
03:30:51 <hongbin> here is what i think: forget about service and replication controller for now
03:31:04 <hongbin> implement pod or container or both in zun at the first step
03:31:27 <hongbin> if we have pod, container is easy (a pod with one container)
03:31:48 <eliqiao> hongbin: hehe ...
03:31:59 <sudipto_> hongbin, agreed.
03:31:59 <hongbin> for docker, we have the sandbox concept now, which makes us easier to implement pod in docker driver
03:32:16 <eliqiao> hongbin: that's tricky
03:32:38 <Qiming> make those things rock solid when we are looking forward to more advanced features and/or use cases
03:32:39 <sudipto_> My point is - make zun self sufficient first and then move on supporting other COEs if at all.
03:32:54 <sudipto_> Qiming, +1
03:32:59 <shubhams> hongbin: yep right.. same priorities we have in our etherpad :)
03:33:03 <shubhams> Qiming: +1
03:33:30 <hongbin> ok, all. i proposed all of us to vote on each option in the etherpad
03:33:32 <hongbin> #link https://etherpad.openstack.org/p/zun-k8s-integration
03:33:53 <hongbin> the etherpad should list all the options we have discussed so far
03:43:05 <hongbin> ok, all
03:43:14 <hongbin> let's work on the etherpad as a homework
03:43:39 <shubhams> hongbin: ok
03:43:42 <hongbin> is everyone still on the etherpad? or back to here?
03:43:48 <kevinz> :D
03:44:02 <hongbin> ok, move on
03:44:04 <hongbin> #topic Support interactive mode (kevinz)
03:44:08 <hongbin> kevinz: ^^
03:45:02 <kevinz> https://review.openstack.org/#/c/396841/
03:45:15 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/support-interactive-mode The BP
03:45:20 <kevinz> Here is the design spec I've updated
03:45:20 <hongbin> #link https://review.openstack.org/#/c/396841/ The design spec
03:45:54 <hongbin> kevinz: maybe you could briefly explain what is the updated idea?
03:46:19 <hongbin> kevinz: because not everyone here has reviewed the updated spec
03:47:30 <kevinz> OK plan to refer to Kubenetes, zun-cli will first connect to zun-api zun-compute to create container
03:48:17 <kevinz> docker daemon will open a tcp port
03:48:51 <kevinz> zun cli will connect to the zun-api then proxy to the tcp port
03:49:16 <kevinz> connect local stdin stderr stdout to this container to realize the interactive
03:49:33 <kevinz> Just like kubernetes does
03:50:05 <hongbin> kevinz: the flow will be: zunclient -> zun-api -> zun-compute -> docker daemon ?
03:50:42 <kevinz> Yeah I think your advice is valuable, change to  zunclient -> zun-api ->docker daemon
03:50:47 <hongbin> i should say: zunclient <-> zun-api <-> zun-compute <-> docker daemon (since the streaming is bidirectional)
03:50:58 <hongbin> ok
03:51:11 <hongbin> then zunclient <-> zun-api <-> docker daemon
03:51:45 <hongbin> i like that, because bypassing zun-compute will reduce some overhead
03:52:14 <hongbin> kevinz: then, the spec looks good to me
03:52:29 <kevinz> Yeah, as first step could we just : zunclient <-> websocket <-> docker-daemon
03:53:04 <kevinz> zunclient ask zun-api for the websocket link, then connect to port directly without token first step?
03:53:36 <hongbin> kevinz: i suggest forgetting the token for now
03:54:09 <hongbin> kevinz: you don't have to implement the authentication at the first iteration
03:54:27 <hongbin> kevinz: i think that will be easier for you
03:54:32 <kevinz> hongbin: OK , that means  ask zun-api for the websocket link, then connect to port directly is fine ?
03:54:41 <hongbin> kevinz: yes
03:54:56 <kevinz> hongbin: COOL I will update the spec
03:55:02 <hongbin> kevinz: after that, you can consider using token / TLS to secure the connection
03:55:09 <kevinz> hongbin: Thanks
03:55:14 <kevinz> yep
03:55:20 <hongbin> sounds good
03:55:41 <hongbin> kevinz: thanks for proposing the spec
03:55:56 <kevinz> hongbin: My pleasure
03:56:02 <hongbin> #topic Open Discussion
03:57:02 <hongbin> ok, if there is nothing else, let's end the meeting a few minutes earlier
03:57:19 <hongbin> #endmeeting