15:03:17 <banix> #startmeeting kuryr 15:03:17 <openstack> Meeting started Tue Jan 26 15:03:17 2016 UTC and is due to finish in 60 minutes. The chair is banix. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:20 <openstack> The meeting name has been set to 'kuryr' 15:03:22 <fawadkhaliq> apuimedo: lol 15:03:25 <apuimedo> it is alive! 15:03:29 <gsagie> maybe it is :) 15:03:33 <apuimedo> :-) 15:03:47 <apuimedo> banix, you are chair and table 15:03:52 <apuimedo> set the topics ;-) 15:03:59 <banix> #chair apuimedo 15:04:00 <openstack> Current chairs: apuimedo banix 15:04:04 <apuimedo> darn 15:04:12 <apuimedo> that happens for talking too much 15:04:17 <banix> :) 15:04:20 <fawadkhaliq> good one banix ;-) 15:04:25 <apuimedo> #topic kubernetes libnetwork usage 15:04:34 <apuimedo> mmm 15:04:44 <irenab> apuimedo: not sure about the topic ... 15:04:53 <apuimedo> seems it doesn't work 15:04:53 <irenab> its either first orsecond ... 15:05:01 <apuimedo> well, everybody read it 15:05:19 <apuimedo> in this topic I would like to go through the current state 15:05:40 <irenab> kube already has CNI support: https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/network/cni 15:05:53 <irenab> and it seems to be the prefered way to go 15:05:55 <apuimedo> and in my opinion I would put to rest the possibility of just holding out for the possibility of just using an eventual libnetwork support 15:06:09 <apuimedo> and relying on configuration to plug to a network 15:06:17 <apuimedo> do we all agree with that? 15:06:25 <gsagie> i do 15:06:26 <vikasc> +1 15:06:28 <irenab> +1 15:06:35 <qwebirc16548> um, what does that mean exactly? 15:06:44 <banix> +0.8 15:06:55 <fkautz> It's unlikely k8s will support libnetwork at this point 15:06:58 <qwebirc16548> I do not see much movement toward libnetwork among the kube community 15:07:00 <baohua_> +0.5 15:07:31 <qwebirc16548> If you do not care about k9s load balancers, we already have all that we need from k8s 15:07:34 <fkautz> Unless something fundamentally changes in either k8s or docker philosophy 15:07:44 <qwebirc16548> we can write a CNI plugin that invokes `docker network` to do what is needed. 15:08:11 <banix> qwebirc16548: that’s what I am wondering if we can do 15:08:18 <irenab> qwebirc16548: can you elaborate? 15:08:24 <qwebirc16548> sure... 15:08:32 <fawadkhaliq> qwebirc16548: not sure its a straight forward mapping 15:08:34 <fawadkhaliq> irenab: +1 15:08:51 <qwebirc16548> In the CNI plugin's add-container-to-network operation, use `docker network` to disconnect from "none" and then connect to the desired network. 15:09:00 <qwebirc16548> This is assuming it can determine the desired network. 15:09:02 <apuimedo> qwebirc16548: doing a CNI plugin that calls docker network is still abandoning direct libnetwork ideas 15:09:12 <qwebirc16548> I am thinking of a simple scenario with one network per k8s Namespace 15:09:33 <apuimedo> qwebirc16548: are you Shu Tao? 15:09:49 <qwebirc16548> When the CNI plugin invokes `docker network`, this goes through libnetwork. So no abandonment there. 15:10:01 <qwebirc16548> No, I am not Shu Tao. But I know him. 15:10:10 <vikasc> qwebirc16548: namespace maps to tenants in k8s 15:10:13 <apuimedo> Mike Spreitzer then I bet :P 15:10:18 <qwebirc16548> bingo 15:10:22 <apuimedo> anyway 15:10:40 <vikasc> qwebirc16548: then one tenant having more networks is very likely 15:10:44 <qwebirc16548> I am supposing each tenant gets one network 15:10:52 <qwebirc16548> Yes, that's the next level 15:11:00 <qwebirc16548> doing that will require more 15:11:09 <vikasc> qwebirc16548: hmm 15:11:21 <apuimedo> doing a CNI translation to the current libnetwork driver is still doing a CNI plugin 15:11:35 <qwebirc16548> so? 15:11:41 <apuimedo> so, can we establish that we are doing that before deciding in which manner go? 15:11:59 <banix> yes, but it will be a simpler one which will be able to utlize our Kuryr plugin 15:12:03 <qwebirc16548> I will do it myself if nobody else gets to it sooner 15:12:31 <apuimedo> ok, moving on 15:12:38 <fkautz> i don't think it'll be that simple, but worth looking into 15:12:39 <gsagie> so you are basically adding lib network support to cabernets, in some way which is probably not optimal but good enough 15:12:41 <apuimedo> #topic CNI plugin 15:12:48 <gsagie> kubernetes 15:12:54 <salv-orlando> gsagie: love that autocorrect 15:12:56 <qwebirc16548> BTW I see work in the k8s networking group that will pass more info, so that a tenant can have multiple networks 15:13:01 <gsagie> :) 15:13:01 <vikasc> cni plugin takes just two args, ADD and DELETE. To utilize it existing kuryr only way is to refactor kuryr 15:13:02 <apuimedo> xD 15:13:23 <apuimedo> qwebirc16548: for the openshift-namespaces 15:13:35 <apuimedo> I also saw that 15:13:45 <salv-orlando> vikasc: which I agree, but what is the contributors' opinion on developing and maintaining both plugins? 15:13:48 <qwebirc16548> Unfortunately I have been away for a week, wrestling with Ursula 15:14:00 <apuimedo> alright, so basically we have two approaches 15:14:09 <banix> vikasc: I think the suggestion is to use the docker (network) API to implement the CNI API 15:14:11 <qwebirc16548> I think I want to make a counter-proposal, that keeps tenant = Namespace, but have not written it yet 15:14:14 <apuimedo> refactor kuryr and have two different frontends, libnetwork and cni 15:14:36 <apuimedo> or have cni be a translation to libnetwork with a bit of extra configuration/assumptions 15:14:50 <baohua_> like this idea 15:14:51 <vikasc> banix: yes, in tha case we will not be able to leverage any of existing work 15:15:07 <banix> vikasc: why not? 15:15:16 <apuimedo> baohua_: which idea? 15:15:33 <baohua_> your idea or two front end but one kuryr, should try leverage current kuryr code at most 15:15:35 <salv-orlando> apuimedo: the latter implies you're assuming CNI will always back docker. 15:15:38 <fkautz> apuimedo: are you suggesting a side channel with extra info passed to support anything libnetwork doesn't? 15:15:50 <salv-orlando> now that might true but at least on the table docker's not the only one 15:15:59 <apuimedo> salv-orlando: well, I'm cheating actually 15:16:11 <salv-orlando> apuimedo: you're so openstack ;) 15:16:14 <apuimedo> I actually think that it is not option 1 or option 2 15:16:36 <apuimedo> I think it is option 1 for right now. Then make a proper option 2 15:16:46 <irenab> apuimedo: can you please identify option 1 and option2, so we can refer during discussion 15:16:50 <baohua_> should not wait the decision from k8s team, so start with option #1 15:16:54 <salv-orlando> I mean option 2 could be a short term implementation for the CNI plugin 15:17:00 <salv-orlando> and then we can iterate over it 15:17:33 <qwebirc16548> can someone please clarify which is 1 and what is 2? 15:17:34 <apuimedo> option T -> translate 15:17:40 <vikasc> banix: i meant whatever we have in kuryr today is libnetwok apis handlers. calling docker network will not fit into cni model 15:17:52 <qwebirc16548> why not? 15:17:53 <apuimedo> option F -> different frontends 15:18:05 <baohua_> option #F can keep the code more clean, and flexible for further possible change. 15:18:22 <apuimedo> baohua_: agreed 15:18:24 <banix> yes, the choice is whether we expand the scope of Kuryr to support container networking (docker and others) through OpenStack networking. I think the answer is yes. 15:18:25 <fkautz> Having worked on building such a bridge, I agree with vikasc 15:18:27 <baohua_> option #T requires assumption they finally get to libnetwork 15:18:29 <apuimedo> IMO that's the way to go for the future 15:18:58 <irenab> so option F is to have CNI to call neutron? 15:19:01 <apuimedo> option T would be something that we use short term an for no longer than the end of the Mitaka cycle 15:19:14 <apuimedo> irenab: that's right 15:19:15 <qwebirc16548> vikasc: why does calling `docker network` CLI not fit into the CNI model? 15:19:59 <fkautz> qwebirc16548: part of it is what info is owned by the user vs libnetwork, e.g. Things like which network namespace is being used is not exposed in libnetwork 15:20:02 <apuimedo> qwebirc16548: I don't think that it can't fit. I think that it may not offer as much potential as a specialized frontend in the mid/long term 15:20:19 <fkautz> K8s wrote a blog post on why libnetwork doesn't work for them on their blog 15:20:24 <vikasc> apuimedo: +1 15:20:26 <fkautz> Many of the concerns will apply here 15:20:28 <vikasc> fkautz: +1 15:20:51 <qwebirc16548> Yes, I read that blog post and agree 15:20:52 <fkautz> But a lot of it is in who owns what and what gets exposed 15:20:54 <banix> #link http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-libnetwork.html 15:20:55 <baohua_> oh, more concerns now. 15:20:57 <qwebirc16548> Both sides have moved on since 15:21:01 <fkautz> Can't make decisions if you don't have the info 15:21:03 <irenab> k8s is not Docker specific, so option T will limit 15:21:18 <fawadkhaliq> irenab: +1 15:21:24 <qwebirc16548> oh, that's newer 15:21:30 <vikasc> irenab: nice point 15:21:40 <baohua_> so we have the same context now 15:21:53 <salv-orlando> I see translation only as a stopgap measure - ie: something that can work while a proper plugin not dependent on libnetwork is implemented 15:21:54 <banix> so let’s back up for a second if you all agree 15:22:06 <irenab> can we drop option T ? 15:22:12 <apuimedo> qwebirc16548: I see value on right now having work on a thin CNI plugin that does network per namespace. 15:22:24 <apuimedo> as salv-orlando says, a stopgap measure 15:22:26 <fkautz> Right, that's my primary concern with a bridge. I would love to see a generic bridge exist. Maybe a bridge specific for Kuryr is more attainable because you can make assumptions 15:22:39 <qwebirc16548> Yes, I suggest starting there and then expanding as both k8s and docker evolve 15:22:52 <banix> the main issue here is that we are saying we want to support all contain run times and if thats the case relying on libnetwork doesn’t make sense. long term. 15:22:54 <banix> right? 15:22:57 <vikasc> i would prefer a seperate plugin sharing libs with libnetwork plugin 15:23:28 <irenab> vikasc: I share same understanding 15:23:30 <apuimedo> banix: that's right. I never intended kuryr to be just a libnetwork driver, but bringing neutron to containers 15:23:30 <salv-orlando> vikasc: I think that's attainable at no cost. 15:23:54 <baohua_> banix: agree, we should expand more. 15:24:02 <vikasc> salv-orlando: i too believe so 15:24:10 <apuimedo> Do we all agree that long term, we see option F as the right one? 15:24:14 <baohua_> apuimedo:+1 15:24:18 <apuimedo> I'll put my +1 15:24:22 <vikasc> +1 15:24:25 <banix> apuimedo: yes 15:24:34 <fkautz> +1 on F 15:25:02 <fawadkhaliq> apuimedo: +1 yes, until there is one option left ;-) 15:25:05 <apuimedo> irenab: ^^, gsagie ^^ 15:25:06 <irenab> +1 15:25:09 <gsagie> +1 15:25:26 <apuimedo> alright, I think we have good enough support 15:25:42 <baohua_> agile decision:) 15:25:46 <irenab> the question if we start with option F or you still want short term option T? 15:25:48 <apuimedo> #info The long term goal is to have different frontends for different platforms 15:26:14 <apuimedo> #topic implementation of a works-now translation layer for Kubernetes (with docker) 15:26:15 <vikasc> my opinion start with F 15:26:19 <baohua_> i suggest start with option #F directly 15:26:23 <irenab> +1 15:26:28 <gsagie> start with option F, we can work in parallel if anyone wants to start working on the T option as well 15:26:33 <apuimedo> first of all 15:26:38 <vikasc> gsagie: +1 15:26:44 <apuimedo> don't get so hasty with the votes :P 15:26:59 <irenab> gsagie: agree, it is ortogonal 15:27:00 <apuimedo> (╯° °)╯彡┻━┻ 15:27:12 <fkautz> +1 chair flip :p 15:27:21 <fkautz> I assume that's a bench 15:27:29 <apuimedo> please qwebirc16548, could you give us more information about the design for the translation layer? 15:27:37 <qwebirc16548> sure 15:27:38 <apuimedo> fkautz: it's a bar stool 15:27:44 <baohua_> guangdang~ 15:27:46 <qwebirc16548> I am thinking of starting simple, as I said... 15:28:08 <qwebirc16548> Actually, in my environment this is all behind another API layer anyway, which makes it easier... 15:28:27 <qwebirc16548> With a k8s NS per tenant, and a network per tenant, all not visible to the real client 15:28:32 <apuimedo> with the level of information that reaches the CNI plugin, qwebirc16548, what is missing for doing the translation? 15:28:34 <qwebirc16548> implicit isolation between tenants 15:28:59 <qwebirc16548> My current understanding is nothing is lacking for my under-the-covers isolation 15:29:10 <qwebirc16548> I can invent a network name based on the Namespace 15:29:11 <irenab> qwebirc16548: seems you assume specific app deployment use case, right? 15:29:13 <qwebirc16548> and away I go. 15:29:23 <qwebirc16548> Yes, like I said. 15:29:35 <irenab> namespace = Tenant? 15:29:36 <qwebirc16548> that is, what I said is all that I assume (that I remember right now) 15:29:40 <qwebirc16548> yes 15:30:06 <irenab> one network per Tenant? 15:30:14 <qwebirc16548> irenab: yes 15:30:30 <qwebirc16548> As I said, my use pattern is implicit isolation between tenants. 15:30:46 <irenab> qwebirc16548: does it correspondsto the kube-sig-net proposel 2? 15:30:55 <salv-orlando> qwebirc16548: which is cool. What would be the corresponding topology in openstack? 15:31:06 <salv-orlando> I ask because we might have to punch holes here and there 15:31:07 <qwebirc16548> Have not had time to study those enough yet. Been wrestling with Ursula. 15:31:18 <irenab> https://docs.google.com/document/d/1W14C03dsBbZi23FN0LmDe1MI0WLV_0-wf_mRxLr2-g4/edit 15:31:19 <apuimedo> would it be a single network, single subnet per tenant? 15:31:53 <irenab> it maybe subnet per Node 15:31:55 <qwebirc16548> Yes, I think one subnet per network 15:32:24 <apuimedo> qwebirc16548: what to do with the cluster ips? 15:32:43 <apuimedo> cause I assume we'd not have kube-proxy running to set iptables redirects for those 15:32:44 <qwebirc16548> in k8s speak, "cluster IPs" are the IPs handed out to the containers,right? 15:32:59 <irenab> to services 15:33:02 <qwebirc16548> Like I said, I have a caveat: we do not care about k8s load balancers 15:33:02 <apuimedo> qwebirc16548: it's an ip that takes you to any of the pods 15:33:08 <baohua_> service layer ip 15:33:27 <apuimedo> in our prototype we use LBaaS for those 15:33:29 <qwebirc16548> Oh, right. The terms are cluster IPs (for the hosts), pod IPs, and service IPs. IIRC 15:33:35 <baohua_> it's not binding with lb 15:33:40 <apuimedo> so we had a separate subnet for cluster ips 15:33:58 <irenab> qwebirc16548: how the service level connectiviy will work without load balancers? 15:34:07 <fkautz> Wouldn't eliminating load balancers effectively eliminate k8s services? 15:34:14 <qwebirc16548> k8s has LBs for services and for ingress resources. 15:34:15 <baohua_> the cluster ip is handled by kube-proxy 15:34:39 <qwebirc16548> The caveat I said means you don't care about k8s services and ingress resources. 15:34:46 <irenab> qwebirc16548: so you plan to keep using kube-proxy as is? 15:34:47 <fkautz> There is a node port for service, but I recall that not being preferred 15:34:53 <qwebirc16548> If you want to use those, then you have to think harder. 15:35:34 <qwebirc16548> No, I mean a starting level of development that does not support k8s services and ingress resources. 15:35:40 <qwebirc16548> that makes kube-proxy irrelevant. 15:36:13 <qwebirc16548> If you want to integrate with kube-proxy then you need non-trivial changes in k8s... 15:36:24 <qwebirc16548> or maybe lots of Neutron work with FWaaS. 15:36:50 <qwebirc16548> I have not finished thinking that through. Been wrestling with Ursula. 15:37:37 <apuimedo> qwebirc16548: Ursula? 15:37:40 <qwebirc16548> we might be able to use FWaaS to do something like what OpenShift did 15:37:52 <qwebirc16548> Ursula is ansible to install OpenStack 15:37:58 <qwebirc16548> (yet another) 15:37:59 <apuimedo> ah! 15:38:07 <apuimedo> no more installers! 15:38:09 <baohua_> yet another! 15:38:12 <irenab> apuimedo: you should have know it ;-) 15:38:17 <qwebirc16548> sorry, it has some local currency 15:38:28 <apuimedo> y=ー( ゚д゚)・∵. 15:38:40 <qwebirc16548> even though too few people seem to recognize the author that gave us the word "ansible" 15:39:01 <fkautz> Nothing wrong with long distance communication! 15:39:07 <fkautz> FTL 15:39:25 <irenab> so back to kube on kuryr, do we have a plan? 15:39:34 <fawadkhaliq> qwebirc16548: apuimedo, I think it would be great if we agree upon on the use case we are trying to address in the stop gap solution and then it will be easier to agree on a solution if any. 15:39:39 <apuimedo> irenab: you mean an option T plan 15:39:57 <qwebirc16548> Do you guys think FWaaS is up to the task? 15:40:00 <apuimedo> fawadkhaliq: precisely. I want to set the minimums 15:40:03 <irenab> fawadkhaliq: +1 on starting with use case 15:40:07 <salv-orlando> irenab: idk it seems to me the plan is to wait for qwebirc16548 to finish his fight with Ursula. 15:40:09 <fawadkhaliq> qwebirc16548: lol nope 15:40:12 <qwebirc16548> If so then I think we can do a stop-gap that uses FWaaS in a pattern like OpenShift did. 15:40:18 <irenab> salv-orlando: :-) 15:40:30 <vikasc> lol 15:40:39 <apuimedo> FWaaS as a requirement is a bit of a non-starter 15:40:46 <apuimedo> I'd rather rely on other primitives 15:40:47 <fawadkhaliq> exactly 15:40:50 <fkautz> the load balancers in open shift is a userspace app, we could use it here maybe? 15:40:55 <irenab> security groups? 15:41:19 <apuimedo> fkautz: LBaaS and security groups should get option T a long way 15:41:21 <qwebirc16548> I think it could be done with SGs, but it's kinda ugly 15:41:33 <qwebirc16548> My deepest worry about SGs is two: 15:41:45 <apuimedo> for that, we should probably make kuryr let you chose sg finally :P 15:41:52 <qwebirc16548> 1 is robustness, 2 is performance of control plane, 3 is performance of data plane 15:41:56 <fkautz> in the long run, I think LBaaS through neutron or another means is best :) 15:41:59 <apuimedo> cause the libnetwork driver still does not let you 15:42:13 <fkautz> User space packet copying will eventually affect perf 15:42:24 <salv-orlando> qwebirc16548: I assume you're referring to neutron ref impl. I wonder why that would not be a worry with fwaas though 15:42:49 <qwebirc16548> Doing the OpenShift pattern with SGs means you limit what can be sent, not what can be received. So one sender that breaks out has complete access to everyone. 15:43:22 <qwebirc16548> salv-orlando: I am discussing worries about using SGs to get isolation between tenants 15:43:34 <qwebirc16548> when kube-proxy is being sued. 15:43:37 <qwebirc16548> used. 15:43:51 <apuimedo> I'm not familiar enough with the reference impl to comment 15:43:53 <salv-orlando> qwebirc16548: service-2-pod networking then. ok. 15:44:06 <irenab> In my opinion we should try to start aligned with kube-sig-net proposal, probably the most basic case 15:44:23 <qwebirc16548> salv-orlando: that's why you have to limit on the sending side. Everyone has to be able to receive from the kube-proxy 15:44:26 <qwebirc16548> proxies 15:44:27 <apuimedo> but, couldn't we start working on the kube-proxy alternative for option F and option T could leverage it? 15:45:06 <qwebirc16548> working on a kube-proxy involves k8s changes... 15:45:12 <qwebirc16548> which are being discussed there. 15:45:13 <apuimedo> as in, no kube-proxy, but something that makes API calls to Neutron 15:45:15 <salv-orlando> apuimedo: that is a viable option but you might want to discuss with k8s upstream too 15:45:59 <apuimedo> salv-orlando: I was thinking pluggability at the k8s API server level actually 15:46:10 <apuimedo> I haven't checked if that requires k8s changes yet 15:46:19 <fkautz> apuimedo: right now is the best time to bring that up 15:46:32 <apuimedo> fkautz: you are completely right 15:46:34 <fkautz> K8s is talking about long term shape of networking 15:46:45 <fkautz> Thursday at I think 5pm est is a meeting for k8s 15:46:47 <fkautz> Definitely join it 15:46:48 <salv-orlando> apuimedo: pluggability in the kube-proxy so far is an if statement where one branch loads the deprecated userspace LB 15:46:53 <irenab> apuimedo: I think it can be done wothout changes, just watching the API objects should be enough, like kube-proxy or skyDNS do 15:47:06 <apuimedo> imho, and with having read the API server 15:47:08 <salv-orlando> it's wedds 2PM PST for this week 15:47:31 <fkautz> Oh, Wednesday this week, good to know. :x 15:47:48 <apuimedo> we (k8s integrators) could get a lot of flexibility out of being able to create entities from the API objects 15:47:59 <apuimedo> and then have the CNI layer just plug into those 15:48:18 <irenab> apuimedo: +1 15:48:22 <apuimedo> (also would help with latency elimination going all the way to neutron and beyond for some things) 15:49:02 <irenab> apuimedo: so CNI mostly for binding? 15:49:13 <apuimedo> that's one way 15:49:51 <apuimedo> banix: I don't see you around ;-) 15:49:54 <irenab> I think it is expected tocall IPAM driver too 15:50:14 <banix> apuimedo: Tables don’t talk much 15:50:46 <apuimedo> irenab: sure. A part of the IPAM would be at CNI level 15:51:14 <irenab> apuimedo: we have 10 mins left. Can you get some summary on next steps? 15:51:20 <apuimedo> in my mind we need either that, or we need to contribute to the kube-proxy pluggability significantly 15:51:54 <apuimedo> because its current level of pluggability, as salv-orlando says, is just not where we'd need it to be for option F 15:52:48 <qwebirc16548> I would like to see a long term design, aligned with ks8 net sig thinking 15:52:49 <salv-orlando> apuimedo: well... you might want to consider running an os-kube-proxy 15:52:57 <qwebirc16548> That requires some thinking and writing on both sides 15:52:57 <apuimedo> Also, we probably will need somewhere to perform the translations of "series of `allofrom`" to Neutron entities 15:53:15 <salv-orlando> at the end of the day k8s components are all loosely coupled bits that communicated with the API server 15:53:25 <qwebirc16548> I am not quite ready to spout the design now. 15:53:29 <fkautz> I agree entirely with qwebirc16548's comment on alignment 15:53:56 <salv-orlando> neither am I - I am just saying let's not constraint ourselves into anything and keep all options on the table 15:54:16 <apuimedo> I agree with that 15:54:37 <apuimedo> Kuryr set out to work as a bridge with the communities 15:54:50 <apuimedo> and we have to be more present in the k8s community right now 15:54:57 <apuimedo> that said 15:55:39 <apuimedo> At least I, need to learn better the options for retrieving the level of information we need for creating the load balancers, modelling allowFrom to subnets, etc 15:56:10 <apuimedo> and it does not sound to me like the idea they had of pushing more and more info to CNI is the right way 15:56:26 <irenab> apuimedo: I think we should decide on the kuryr components/libs 15:56:42 <apuimedo> (it sounds a bit too much like the problems we've had with the slightly arbitrary kind of information we get from libnetwork) 15:57:10 <apuimedo> irenab: ? 15:57:39 <irenab> we may need some API watcher , which does not fit well into kurrent on node kuryr service 15:57:43 <apuimedo> what I'd like to do, as it appears simpler in my mind is to first 15:58:14 <apuimedo> 1.- Take a few Kubernetes typical usages and redraw them using Neutron components 15:58:29 <apuimedo> 2. find the best places in k8s to create them 15:58:56 <apuimedo> 3. Make those possible in k8s if they are not or settle for good approximations 15:59:30 <apuimedo> 2-3 need quite a bit of participation upstream 16:00:15 <apuimedo> qwebirc16548: Do you want to replicate the OpenShift networking model or something a bit different? 16:00:48 <irenab> qwebirc16548: any link you can share on openShift network model? 16:00:49 <qwebirc16548> I'm not real enthused about that one, but it's an existing design that works in k8s without doing violence to it. 16:01:05 <qwebirc16548> I do not have a link. I can write very briefly here, then have to go to next mtg. 16:01:15 <qwebirc16548> Each tenant has one private network 16:01:33 <qwebirc16548> each VM/container can send to any other on the private network (subject to SGs) and to services 16:01:37 <qwebirc16548> I am not sure which ones 16:01:45 <qwebirc16548> Mainly tenant's own services, I suppose 16:02:04 <qwebirc16548> Later 16:02:16 <fawadkhaliq> irenab: https://docs.openshift.com/enterprise/3.0/architecture/additional_concepts/networking.html 16:02:23 <irenab> thanks 16:02:34 <apuimedo> #link https://docs.openshift.com/enterprise/3.0/architecture/additional_concepts/networking.html 16:03:08 <irenab> I would say we need to identigy the use case to support first 16:03:20 <fawadkhaliq> irenab: +1 16:03:36 <fkautz> and unfortunately, that is still a moving target, but I think we have enough now that we can approximate 16:04:07 <apuimedo> fkautz: it is a moving target indeed. But we can help moving it 16:04:14 <fkautz> +1 16:04:19 <apuimedo> if we agree on what we want it to be 16:04:25 <fawadkhaliq> fkautz: agree. we can plan for it 16:04:41 <fawadkhaliq> apuimedo: exactly 16:04:54 <apuimedo> that's why I said I wanted to translate deployment configurations into neutron primitives 16:04:58 <apuimedo> agree on those 16:05:13 <apuimedo> and then help move the k8s target to make those possible 16:05:25 <irenab> apuimedo: this is right, we need to identify the scenario we want to support 16:05:51 <apuimedo> so far it seems like they are still planning for different modes 16:05:56 <irenab> shall we start some use cases doc/etherpad? 16:05:58 <apuimedo> one where there is full isolation 16:06:08 <banix> apuimedo: time for a few action items 16:06:14 <apuimedo> and every connectivity is defined via allowfrom 16:06:23 <vikasc> irenab: can we use existing k8s etherpad? 16:06:32 <irenab> lets add a section there 16:06:38 <apuimedo> and another mode where there is connectivity between pods but services require the allowfrom 16:06:42 <apuimedo> banix: agreed 16:07:01 <fkautz> Link? 16:07:06 <irenab> vikasc: we already have use cases section :-) 16:07:11 <irenab> https://etherpad.openstack.org/p/kuryr_k8s 16:07:18 <irenab> need to add content 16:07:22 <fkautz> Thanks, I'll contribute to it as well 16:07:25 <fawadkhaliq> #link https://etherpad.openstack.org/p/kuryr_k8s 16:07:35 <vikasc> irenab: lets do :) 16:07:37 <apuimedo> #action everybody come to next monday meeting with a translation of deployments into neutron primitives 16:07:49 <apuimedo> please put a link to the diagram in the etherpad 16:08:06 <irenab> apuimedo: so we can have few to chose from :-) ? 16:08:16 <apuimedo> irenab: or rather to converge 16:08:23 <irenab> +1 16:08:36 <apuimedo> who can make tomorrow's meeting with k8s-sig-net? 16:08:52 <fkautz> I will be there 16:08:59 <banix> i can 16:09:05 <vikasc> vikasc: i will also attend 16:09:07 <apuimedo> I'll do my best to make it too 16:09:14 <irenab> same here 16:09:24 <fawadkhaliq> will try 16:09:40 <apuimedo> #action fkautz banix vikasc irenab to try to find out on the pushing infor to CNI versus pluggability at a higher level 16:09:56 <apuimedo> fawadkhaliq: if you can try as well even better :-) 16:10:21 <fawadkhaliq> apuimedo: will do :-) 16:10:36 <apuimedo> banix: do you think qwebirc16548 could come to next kuryr meeting with a bit more defined plan for option T 16:10:40 <apuimedo> so we can decide on it 16:11:09 <apuimedo> in the worst case. I believe that option F should be developed in a way that still allows for option T to happen 16:11:10 <banix> apuimedo: will talk to him but you know Ursala is pretty merciless ;) 16:11:30 <apuimedo> ¯\_(ツ)_/¯ 16:11:32 <banix> i agree 16:11:38 <fawadkhaliq> rofl 16:11:49 <apuimedo> installers are a plague 16:11:55 <apuimedo> anyway 16:12:16 <apuimedo> I'd like to have more info on option T to see the level of effort that would have to go into it 16:12:23 <apuimedo> and if we can make it for Mitaka 16:13:01 <apuimedo> banix: irenab gsagie vikasc fawadkhaliq fkautz: any action I am missing? 16:13:02 <banix> so we are going to discuss during the weekly meeting next week? and then of need be another of these meetings I suppose 16:13:31 <apuimedo> I'd rather have it in the usual slot next week. If we see that the meetings start to overflow 16:13:38 <apuimedo> we can make a kuryr-sig-k8s 16:13:40 <apuimedo> :P 16:13:43 <irenab> banix: I think we agreed to adduse cases in the etherpad 16:13:54 <banix> yes 16:13:54 <fawadkhaliq> apuimedo: nope. looks good. it's a good start. 16:13:57 <apuimedo> going once 16:14:13 <apuimedo> •_•) 16:14:14 <banix> #endmeeting