03:00:10 <hongbin> #startmeeting zun
03:00:11 <openstack> Meeting started Tue Jun 28 03:00:10 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:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:14 <openstack> The meeting name has been set to 'zun'
03:00:17 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-06-28_0300_UTC Today's agenda
03:00:22 <hongbin> #topic Roll Call
03:00:33 <namrata> Namrata
03:00:37 <yanyanhu> hi
03:00:43 <haiwei> hi
03:00:46 <Wenzhi> hi
03:00:51 <mkrai> Madhuri Kumari
03:01:09 <eliqiao> hi
03:01:43 <hongbin> Thanks for joining the meeting namrata yanyanhu haiwei Wenzhi mkrai eliqiao
03:01:52 <hongbin> Pause a few more minutes
03:02:42 <flwang> o/
03:02:49 <hongbin> flwang: hey
03:02:52 <hongbin> #topic Announcements
03:02:59 <hongbin> Our IRC channel has been rename to #openstack-zun. The old channel #openstack-higgins is deprecated.
03:03:05 <hongbin> #link https://review.openstack.org/#/c/330017/
03:03:26 <hongbin> The above patch was landed. That means all the bots are moved to the new channel
03:03:36 <hongbin> The old channel will be duplicated
03:03:45 <eliqiao> hongbin: we can kick, or force more guys in openstack-higgins to openstack-zun
03:03:59 <yanyanhu> :)
03:04:07 <hongbin> Yes, I am figuring out how to do that
03:04:16 <hongbin> eliqiao: will work with you offline
03:04:17 <yanyanhu> anyway to 'move' people from one channel to another ?
03:04:18 <sudipto> o/ sorry a bit late.
03:04:30 <yanyanhu> hi, sudipto
03:04:32 <hongbin> sudipto: hey. NP
03:04:35 <mkrai> Send out an ML
03:04:43 <hongbin> mkrai: good idea
03:04:51 <sudipto> yanyanhu, hongbin hello :)
03:05:02 <hongbin> However, there is a way to forward from old channel to new channel
03:05:21 <hongbin> I tried that but it seems I don't have permission to execute the commands
03:05:27 <shubham_> o/ Hi , Its my first meeting here. I am shubham and I have knowledge on dockers and python.  I am looking forward to contribute to Zun project
03:05:38 <sudipto> welcome shubham_
03:05:40 <mkrai> Hi shubham_
03:05:46 <hongbin> shubham_: welcome
03:05:49 <yanyanhu> welcome
03:05:54 <mkrai> You're welcome
03:05:58 <Wenzhi> welcome
03:05:58 <hongbin> shubham_: which company you belong to?
03:06:15 <shubham_> individual
03:06:19 <hongbin> I see
03:06:22 <Wenzhi> cool
03:06:31 <shubham_> Thanks all for your warm welcome
03:07:08 <hongbin> OK. About the channel rename
03:07:11 <hongbin> Any further comment?
03:07:32 <hongbin> #topic Review Action Items
03:07:34 <hongbin> None
03:07:39 <hongbin> #topic Architecture design
03:07:45 <hongbin> #link https://etherpad.openstack.org/p/zun-architecture-decisions
03:08:02 <hongbin> We are debating the design options in the last meeting
03:08:28 <hongbin> And the options were written down in the etherpad above
03:08:46 <hongbin> Does everyone have a chance to go though the etherpad?
03:09:00 <mkrai> Yes
03:09:14 <sudipto> hongbin, i think your design option 1.1 kind of bridges the gap between people who want to do a COE vs who want to integrate with the COEs. From a desire per say.
03:09:14 <yanyanhu> yes, I'm there
03:09:17 <mkrai> Looks we have multiple option
03:09:29 <mkrai> Agree sudipto
03:09:37 <yanyanhu> sudipto, have the same feeling
03:09:45 <hongbin> sudipto: flwang suggested this option :)
03:10:06 <hongbin> credits to flwang
03:10:08 <sudipto> flwang, ++
03:10:11 <yanyanhu> thanks, flwang :)
03:10:25 <mkrai> cool flwang
03:10:34 <eliqiao> flwang: thx man!
03:10:38 <yanyanhu> so we are in the same page now :)
03:10:49 <Wenzhi> cool flwang
03:11:01 <hongbin> seems like we are on the same page. Option 1.1?
03:11:15 <yanyanhu> +1
03:11:18 <sudipto> +1
03:11:21 <mkrai> +1
03:11:21 <Wenzhi> +1
03:11:38 <flwang> wow, i got a lot of +1
03:11:50 <yanyanhu> haha
03:11:57 <hongbin> If there is any opossing point of view, now it is the time to speak up
03:12:39 <mkrai> hongbin, flwang I think first let's describe the option little bit
03:12:46 <sudipto> flwang, hongbin - just a little concern over point iv)
03:12:47 <mkrai> So that everyone here gets the idea
03:12:56 <eliqiao> iv) One way to alleviate the weakness above is to build custom COEs dedicated for OpenStack (i.e. Hypernetes), which is design option #4. However, it is not recommanded because it violates the principles of "community first".
03:12:57 <sudipto> it doesn't seem to conclude what we mean there.
03:13:25 <sudipto> and is kind of the anit-pattern :)
03:13:33 <sudipto> s/anit/anti
03:14:03 <hongbin> That means basically port COEs to openstack
03:14:10 <hongbin> like Hypernetes
03:14:36 <sudipto> i think the "like hypernetes" confused me...
03:14:36 <hongbin> However, maintain a folk is not trivial
03:14:50 <flwang> firstly i think we're not breaking the 'community first'
03:14:52 <flwang> because
03:14:53 <hongbin> sudipto: Hypernetes ported Kubernetes to OpenStack
03:14:58 <flwang> we do support k8s
03:15:02 <sudipto> hongbin, ah - got it now.
03:15:07 <flwang> and we leave the option to cloud admin/operator
03:15:28 <flwang> let's say, if our native built-in COE is sucks
03:15:35 <flwang> then cloud admin/operator can use k8s
03:15:42 <flwang> if we're doing better job
03:15:43 <hongbin> flwang: The principle of community first, code second, means always contribute to upstream, no folk
03:15:46 <flwang> ....
03:15:48 <flwang> so anyway
03:15:52 <Wenzhi> agree flwang
03:15:54 <sudipto> flwang, that sounds good.
03:16:05 <yanyanhu> sounds good to me.
03:16:09 <flwang> i'm putting my devops hat
03:16:22 <flwang> another story maybe not related is
03:16:32 <flwang> think about vmware in openstack community
03:17:03 <hongbin> OK
03:17:10 <flwang> you got my point
03:17:38 <hongbin> I am going to mark option 1.1 as agreed
03:17:51 <flwang> hongbin: we should draft it as a spec
03:18:01 <sudipto> hongbin, flwang agreed.
03:18:02 <flwang> and send a request to ML for spec review
03:18:05 <hongbin> flwang: sure
03:18:27 <hongbin> #agreed Design options 1.1 (amendment of option 1): Abastract COEs, and provide a native/built-in COE that abstract container runtimes
03:18:40 <hongbin> #action hongbin draft a spec for design option 1.1
03:18:51 <hongbin> That concludes the design of Zun
03:19:00 <hongbin> (high level design)
03:19:10 <hongbin> Next topic
03:19:10 <sudipto> hongbin, with you on this one...reviews/drafting of the same. if you need anything.
03:19:30 <hongbin> sudipto: I will put the draft into an etherpad
03:19:38 <sudipto> hongbin, cool.,
03:19:40 <hongbin> So everyone will collaborate
03:19:48 <hongbin> #topic API design
03:19:52 <yanyanhu> thanks, will help as well
03:19:56 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/api-design The BP
03:20:03 <hongbin> #link https://etherpad.openstack.org/p/zun-containers-service-api Etherpad
03:20:17 <hongbin> mkrai: you want to lead the discussion?
03:20:24 <mkrai> Yes
03:20:55 <mkrai> So last time we discussed about API design, we had discussion on supporting COEs or not
03:21:32 <mkrai> IMO the API design we have will remain the same
03:21:48 <mkrai> What do you guys think?
03:22:07 <sudipto> mkrai, you mean replace the CRUD from  containers to Clusters?
03:22:17 <haiwei> what do you mean by remaining the same?
03:22:52 <mkrai> We will still have CRUD operation that applies to all COEs
03:22:56 <mkrai> Isn't it?
03:23:25 <yanyanhu> no I think?
03:23:40 <yanyanhu> CRUD for COEs is now supported by Magnum?
03:23:47 <yanyanhu> my understanding
03:24:00 <hongbin> magnum supports CRUD for bays
03:24:01 <yanyanhu> I mean creating, deleting, updating of COE clusters
03:24:10 <sudipto> something like v1/cluster1?container=xyz is possible? (CRUD on that)
03:24:10 <hongbin> Yes
03:24:28 <Wenzhi> yanyanhu: that's magnum's scope
03:24:35 <hongbin> Why we consider clusters?
03:24:39 <yanyanhu> Wenzhi, yes
03:24:46 <yanyanhu> hongbin, have the same question
03:24:48 <mkrai> yanyanhu, I don't meant that
03:25:05 <eliqiao> I still think on this design, zun is looks like old magnum
03:25:11 <mkrai> sudipto, What is cluster1 here? Nodes running the COEs?
03:25:11 <yanyanhu> mkrai, ok, my misunderstanding :)
03:25:12 <Wenzhi> should not we support CRUD for containers in Zun?
03:25:33 <eliqiao> (away from pod CRUD)
03:25:37 <sudipto> hongbin, mkrai cluster1 per design 1.1 is set of containers .
03:25:55 <yanyanhu> sudipto, I see
03:26:01 <yanyanhu> cluster of container, not COE cluster
03:26:07 <haiwei> it seems magnum also support CRUD of containers, wenzhi
03:26:10 <sudipto> yanyanhu, yeah
03:26:24 <Wenzhi> got it, yanyanhu
03:26:27 <mkrai> haiwei, No Magnum doesn't
03:26:27 <hongbin> haiwei: No, magnum removes its container endpoints
03:26:39 <haiwei> ok, got it
03:26:41 <eliqiao> Magnum won't support container CRUD
03:27:00 <Wenzhi> so cluster in Zun means composition of containers, right?
03:27:09 <sudipto> Wenzhi, i thought so...
03:27:14 <sudipto> however, i do feel we have to abstract that 'cluster of containers' into some sort of an abstract entity that applies to all coes?
03:27:17 <mkrai> hongbin, sudipto Is it not like user will say create me a container of type kubernetes or swarm?
03:27:51 <sudipto> mkrai, i would imagine so. for the user it's about the cluster, for the operator - it's about which COE driver to use.
03:28:02 <eliqiao> mkrai: that will looks like old Magnum APIs.
03:28:36 <mkrai> Everyone I think there is understanding gap on design point 1.1
03:28:37 <hongbin> One thing to clarify, Magnum supports provisioning COEs, zun supports interfacting with COEs
03:28:49 <yanyanhu> sudipto, agree. Just feel we need both container primitive and cluster
03:28:49 <mkrai> Everyone has different understanding :D
03:28:56 <eliqiao> For users: get me a container, For operation admin: get me a cluster which can have containers run on top of it.
03:29:02 <mkrai> hongbin, +1
03:29:06 <yanyanhu> and the latter one is based on the formal one
03:29:19 <yanyanhu> s/formal/former
03:29:31 <sudipto> yanyanhu, i guess that's the reason i said cluster?container=xyz - in case of a single container - the cluster probably just has one entity...
03:29:55 <eliqiao> hongbin: actually, old Magnum has some zun's work (interface part) ?
03:29:57 <yanyanhu> sudipto, I see, so you suggest we use 'cluster' as the name of Zun primitive
03:29:58 <mkrai> eliqiao, We are abstracting COEs, so it means we are running container on any of the COEs
03:30:17 <sudipto> yanyanhu, not crazy about the name, just using it as a symbolic representation :)
03:30:20 <hongbin> eliqiao: Yes, but the "old magnum" don't have a unified API layer
03:30:26 <eliqiao> mkrai: I know that, but zun should know what COE is running
03:30:30 <yanyanhu> which could be a single container or a set of container
03:30:36 <yanyanhu> I see
03:30:42 <mkrai> eliqiao,  Yes it should
03:30:58 <eliqiao> hongbin: bingo, I get it (they do have pod/containes) and now I will unify it as "container"
03:31:01 <Wenzhi> can we treat COEs as hypervisors for container?
03:31:29 <mkrai> Wenzhi,  Yes i think so
03:31:32 <eliqiao> then zun will fall back to a API gateway ?
03:31:33 <hongbin> Wenzhi: you can think this way
03:31:54 <yanyanhu> eliqiao, I think the developer and operator of Zun will know the existence of backend COEs, but for enduser, those COEs are transparent I think
03:31:54 <eliqiao> COEs are provisoned by Magnum and Zun just do the interface to COEs?
03:32:25 <hongbin> eliqiao: It seems you are right
03:32:28 <sudipto> eliqiao, broadly - one use case like that. which could be that magnum does the provisoning and hands over the cluster to zun - to now do things with it.
03:32:29 <yanyanhu> end users don't need to know who(which COE) is at the backend
03:32:36 <hongbin> eliqiao: Besides, Zun provides a native COE
03:32:38 <eliqiao> hongbin: then do we still need zun-agent on each node?
03:32:45 <hongbin> eliqiao: yes
03:33:17 <sudipto> eliqiao, we had this discussion with hongbin on the channel, some of his concerns were not to tie it tightly with magnum - it's one way to imagine it.
03:33:17 <xiangxinyong> It seems that zun is above magnum.
03:33:21 <eliqiao> hongbin: so the zun-agent only requrired by our nagive COE, right?
03:33:26 <mkrai> eliqiao, We will also have some Openstack native COE
03:33:29 <eliqiao> xiangxinyong: you got it.
03:33:39 <yanyanhu> eliqiao, I think that means Zun support different COEs and the built-in one(proposed in option1.1) is one of them
03:33:47 <hongbin> eliqiao: yes zun-agent is only for native COE
03:33:49 <eliqiao> yanyanhu: agreed
03:33:58 <eliqiao> hongbin: ah
03:34:08 <eliqiao> I am now get it all!
03:34:20 <yanyanhu> eliqiao, you're right about the zun-agent I think
03:34:31 <eliqiao> ++ for option 1.1
03:34:52 <hongbin> For the disucssion of cluster
03:35:05 <haiwei> if we put zun above magnum, there is no need to integrate with Nova?
03:35:10 <hongbin> I don't think we need to worry about that , until we work on magnum integration
03:35:10 <eliqiao> the things we need to figure out is how to mapping other COEs 'container/pods' to zun's container object.
03:35:25 <mkrai> Ok so now for API we need to find a term represents a group of container
03:35:31 <sudipto> eliqiao, precisely!
03:35:37 <hongbin> haiwei: No, we need to integrate with Nova as well
03:35:51 <Wenzhi> agree eliqiao
03:35:55 * sudipto thinks since we are sort of agreed on the design, we could discuss the implementation design next on an etherpad.
03:36:12 <eliqiao> hongbin: haiwei integrate with nova is for our native COE, I think.
03:36:43 <mkrai> eliqiao, IMO it can be any COE
03:37:06 <hongbin> There are two things that is confusing. 1. Zun itself, 2. Zun's native COE
03:37:35 <hongbin> Actually, we needs two APIs for above
03:37:42 <hongbin> (I think)
03:37:57 <hongbin> One set of APIs for #1, another set of APIs for #2?
03:38:10 <sudipto> hongbin, zun itself is just a container?
03:38:23 <sudipto> hongbin, that is what do you mean by #1
03:38:34 <hongbin> sudipto: zun itself is an layer to abstract COE
03:39:06 <sudipto> hongbin, ah got it...basically you want to have two different APIs - 1. for abstraction 2. for native zun COE...
03:39:06 <sudipto> ?
03:39:22 <hongbin> That is the idea in my mind
03:39:26 <Wenzhi> request->Zun API->Zun COE API?
03:39:34 <hongbin> Yes
03:39:42 <shubham_> hongbin: I think #2 resembles other COEs in magnum and can be used in magnum as inbuilt api along with docker, kubernetes etc ?
03:39:43 <mkrai> hongbin, isn't it possible to abstract both?
03:39:43 <eliqiao> we can call it as instance too, which means abstract layer of COEs.
03:40:08 <yanyanhu> eliqiao, +1
03:40:17 <hongbin> shubham_: Magnum should belong to provisioning COEs only
03:40:27 <yanyanhu> mkrai, it could be I think
03:40:31 <hongbin> mkrai: Maybe, that is an alternative
03:40:44 <sudipto> hongbin, i think what shubham_ means that if zun becomes a COE, it probably can be provisioned via magnum or something like that :)
03:40:57 <shubham_> +1 sudipto
03:41:23 <hongbin> sudipto: Yes, magnum integration is possible
03:41:40 <Wenzhi> if Zun native COE becomes mature in the future, maybe we can split it out from Zun to a new project
03:42:07 <eliqiao> then we compete with other COES :(
03:42:25 <yanyanhu> eliqiao, if it's really good, why not :)
03:42:26 <hongbin> Wenzhi: sure. That is how neutron-lbaas and octavia works
03:42:31 <flwang> Wenzhi: don't say that :D
03:42:40 <Wenzhi> eliqiao: if it's mature and stable, we can compete them
03:42:43 <mkrai> Eventually we are going it even if we don't want it :D
03:42:46 <Wenzhi> haha
03:42:47 <yanyanhu> but if it is not good enough, it will be just a reference
03:42:53 <Wenzhi> it's too early to say that
03:42:58 <flwang> guys
03:43:10 <hongbin> Yes, the key work: reference implementation
03:43:10 <flwang> if you want to get approval from the board
03:43:25 <flwang> let's say the built-in implement is just a reference for testing
03:43:27 <flwang> for now
03:43:33 <flwang> you can make it better if you want
03:43:42 <flwang> you can even make it better than k8s
03:43:42 <eliqiao> flwang: you are a old bird :)
03:43:44 <flwang> your choice
03:43:46 <eliqiao> s/a/an
03:43:56 <mkrai> Ok so now we need to redesign our API endpoints
03:43:57 <Wenzhi> got it
03:44:05 <flwang> just my 0.02
03:44:12 <mkrai> Please write down your views on etherpad
03:44:35 <hongbin> flwang: agree. Officially, I would like to say it is an reference implementation
03:44:46 <mkrai> hongbin, Do you think the current one applies to Zun itself option?
03:45:04 <hongbin> mkrai: ??
03:45:33 <mkrai> Ok so you said there can be two sets of API. #1 Zun itself
03:45:47 <mkrai> It means the API for Zun COE
03:46:01 <hongbin> That needs to be discussed further
03:46:26 <mkrai> Ok
03:46:27 <hongbin> If we want it to be a reference COE, it should have its own set of APIs
03:46:40 <Wenzhi> agree
03:46:59 <mkrai> Yes not simply a wrapper over docker
03:47:24 <hongbin> mkrai: I think it is a wrapper of container runtims
03:47:29 <mkrai> So we need to redesign our APIs
03:47:41 <mkrai> Agree hongbin
03:47:50 <hongbin> mkrai: I think the design is good so far
03:48:29 <mkrai> hongbin, I meant like k8s we have similar concept of pod?
03:48:29 <hongbin> OK. Folks. To avoid confusion, we need to decide which one to start first
03:48:45 <hongbin> #1 Zun API layter, #2 Zun's reference implementatoin of COE
03:49:11 <hongbin> If #1, we design a API for COEs
03:49:20 <hongbin> If #2, we design an API for container runtimes
03:49:37 <mkrai> #2 first
03:49:45 <yanyanhu> agree with mkrai
03:49:50 <sudipto> I think the API abstraction/design is the key. So the etherpad sounds like a good idea to start discussion. I am in two minds about two different zun APIs at the moment...but i need to think through.
03:49:51 <Wenzhi> +1
03:49:57 <yanyanhu> since if we want to use it as reference, it should be there first
03:50:30 <flwang> here is an api ref if you guys interested in :)  http://docs.aws.amazon.com/AmazonECS/latest/APIReference/Welcome.html
03:50:36 <hongbin> sudipto: We can discuss that further
03:50:55 <flwang> given we have agreed to go to #1.1, basically we're doing the similar thing as ECS
03:51:13 <flwang> more or less
03:51:18 <hongbin> flwang: Frankly, I think everyone complains about ECS APIs :)
03:51:35 <hongbin> #link https://railsadventures.wordpress.com/2015/12/06/why-we-chose-kubernetes-over-ecs/
03:51:41 <flwang> hongbin: if we can figure out what is bad, that's good
03:52:11 <hongbin> flwang: In the summit, the feedback is : It is bad because it is not a kubernetes API :)
03:52:19 <flwang> haha
03:52:27 <flwang> that's a good excuse
03:52:40 <hongbin> :)
03:53:10 <hongbin> mkrai: For the API design, I think we can start with the reference COE design
03:53:11 <flwang> but before competing with google, at least we can beat yahoo
03:53:34 <yanyanhu> flwang, :)
03:53:40 <flwang> that's a bad example, just kidding
03:53:41 <mkrai> Ok cool
03:53:43 <hongbin> mkrai: Then, the one in your etherpad looks good, after crossing out k8s
03:53:46 <yanyanhu> yahoo is not happy to listen this
03:54:05 <flwang> i'm kidding :)
03:54:08 <hongbin> #topic Open Discussion
03:54:10 <yanyanhu> sure :P
03:54:20 <mkrai> I will try to write a spec for it in this week
03:54:21 <flwang> my point is
03:54:29 <flwang> at least we can learn something from ecs
03:54:41 <hongbin> sudipto: we will discuss with you about the idea of two set of APIs
03:54:55 <hongbin> sudipto: Just find a time offline. We can talk
03:54:55 <mkrai> hongbin, I will also like to join
03:55:06 <sudipto> hongbin, sounds sweet!
03:55:07 <mkrai> Please let me know the timing
03:55:10 <hongbin> mkrai: will ping you
03:55:18 <mkrai> Thanks
03:55:42 <yanyanhu> flwang, agree
03:56:16 <hongbin> flwang: we can learn something from k8s as well (why it is so success)
03:56:49 <sudipto> that space is crowded to be honest...there are complaints on k8s being complicated to use as opposed to docker swarm
03:56:53 <sudipto> but that's for another day really.
03:57:13 <hongbin> sudipto: I see
03:57:23 <hongbin> So, k8s is not perfect
03:57:51 <sudipto> I think once we are settled into the design, a fast prototype would be nice to have. after all, there
03:57:57 <yanyanhu> no one is :) that's why they are all still alive :P
03:58:08 <sudipto> https://groups.google.com/forum/#!topic/google-containers/ii5X7vtYH3o
03:58:31 <sudipto> i mean after all, this space is all about speed - whether it's boot time or it's product release time :)
03:58:46 <hongbin> interesting
03:59:10 <hongbin> OK. Time is up
03:59:18 <yanyanhu> nice, will learn it
03:59:22 <hongbin> All. Thanks for joining hte meeting
03:59:29 <yanyanhu> thanks
03:59:31 <hongbin> Discussion continue offline
03:59:37 <hongbin> #endmeeting