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