| *** outofmemory is now known as reedip | 00:04 | |
| *** salv-orl_ has quit IRC | 00:17 | |
| *** diogogmt has quit IRC | 00:28 | |
| openstackgerrit | Reedip proposed openstack/kuryr: Add report to coverage https://review.openstack.org/272337 | 00:39 |
|---|---|---|
| *** yuanying has joined #openstack-kuryr | 01:10 | |
| *** yuanying_ has quit IRC | 01:11 | |
| *** apuimedo has quit IRC | 01:13 | |
| *** apuimedo has joined #openstack-kuryr | 01:14 | |
| *** salv-orlando has joined #openstack-kuryr | 01:17 | |
| *** salv-orlando has quit IRC | 01:20 | |
| *** diogogmt has joined #openstack-kuryr | 01:24 | |
| *** baohua has joined #openstack-kuryr | 01:49 | |
| openstackgerrit | Fawad Khaliq proposed openstack/kuryr: Networking for nested containers(workinprogress) https://review.openstack.org/269039 | 01:54 |
| *** salv-orlando has joined #openstack-kuryr | 01:54 | |
| *** salv-orlando has quit IRC | 01:59 | |
| *** yuanying has quit IRC | 02:00 | |
| *** yuanying has joined #openstack-kuryr | 02:03 | |
| *** apuimedo has quit IRC | 02:07 | |
| *** apuimedo has joined #openstack-kuryr | 02:08 | |
| *** salv-orlando has joined #openstack-kuryr | 02:19 | |
| *** fawadkhaliq has joined #openstack-kuryr | 02:21 | |
| *** yuanying has quit IRC | 02:25 | |
| *** salv-orlando has quit IRC | 02:27 | |
| *** yuanying has joined #openstack-kuryr | 02:27 | |
| *** diogogmt has quit IRC | 02:28 | |
| *** wanghua has joined #openstack-kuryr | 02:35 | |
| *** fawadkhaliq has quit IRC | 02:38 | |
| *** kexiaodong has quit IRC | 02:40 | |
| *** tfukushima has joined #openstack-kuryr | 02:40 | |
| *** tfukushima has quit IRC | 02:41 | |
| *** salv-orlando has joined #openstack-kuryr | 02:41 | |
| *** tfukushima has joined #openstack-kuryr | 02:42 | |
| *** salv-orlando has quit IRC | 02:48 | |
| *** fawadkhaliq has joined #openstack-kuryr | 02:54 | |
| *** apuimedo has quit IRC | 02:57 | |
| *** apuimedo has joined #openstack-kuryr | 03:06 | |
| *** kexiaodong has joined #openstack-kuryr | 03:06 | |
| *** diogogmt has joined #openstack-kuryr | 03:17 | |
| *** yuanying_ has joined #openstack-kuryr | 03:19 | |
| *** yuanyin__ has joined #openstack-kuryr | 03:20 | |
| *** yuanying has quit IRC | 03:22 | |
| *** yuanying_ has quit IRC | 03:23 | |
| *** yuanyin__ has quit IRC | 03:29 | |
| *** yuanying has joined #openstack-kuryr | 03:29 | |
| tfukushima | baohua: Although you are assigned to https://bugs.launchpad.net/kuryr/+bug/1516539, can I add "sudo" to the command to run Kuryr in README.rst? | 03:50 |
| openstack | Launchpad bug 1516539 in kuryr "failed to start Docker container with network created by kuryr" [High,In progress] - Assigned to Baohua Yang (yangbaohua) | 03:50 |
| tfukushima | I found it'd be confusing in general. | 03:50 |
| *** banix has quit IRC | 03:54 | |
| openstackgerrit | Taku Fukushima proposed openstack/kuryr: Add "sudo" to the instruction for running Kuryr https://review.openstack.org/272370 | 03:54 |
| openstackgerrit | Taku Fukushima proposed openstack/kuryr: Add "sudo" to the instruction for running Kuryr https://review.openstack.org/272370 | 03:56 |
| tfukushima | baohua: I submitted the patch. If you were already working on it, I'll abandon it so please let me know in that case. | 03:57 |
| tfukushima | It'd be a temporarily workaround. | 03:57 |
| *** yuanying has quit IRC | 03:57 | |
| *** yuanying has joined #openstack-kuryr | 03:58 | |
| *** yuanying has quit IRC | 04:02 | |
| *** yuanying has joined #openstack-kuryr | 04:08 | |
| *** fawadkhaliq has quit IRC | 04:12 | |
| *** fawadkhaliq has joined #openstack-kuryr | 04:32 | |
| *** diogogmt has quit IRC | 04:56 | |
| baohua | sure, tfukushima, i will talked with toni to see if more solutions. | 05:03 |
| *** tfukushima has quit IRC | 05:16 | |
| *** tfukushima has joined #openstack-kuryr | 05:50 | |
| *** tfukushima has quit IRC | 06:05 | |
| *** tfukushima has joined #openstack-kuryr | 06:07 | |
| *** fawadkhaliq has quit IRC | 06:13 | |
| *** irenab has quit IRC | 06:24 | |
| *** apuimedo has quit IRC | 06:29 | |
| *** vikasc has joined #openstack-kuryr | 06:35 | |
| *** salv-orlando has joined #openstack-kuryr | 06:38 | |
| vikasc | baohua, hi | 06:41 |
| *** salv-orlando has quit IRC | 06:42 | |
| *** gsagie has quit IRC | 06:43 | |
| vikasc | tfukushima, ping | 06:44 |
| *** salv-orlando has joined #openstack-kuryr | 06:56 | |
| baohua | hi vikasc | 07:06 |
| vikasc | baohua, just to confirm | 07:09 |
| vikasc | baohua, we have k8s integration meeting at 15:00 UTC today | 07:10 |
| vikasc | baohua, ? | 07:10 |
| baohua | the meeting is discussion about the support of the cni model (https://github.com/appc/cni/blob/master/SPEC.md) | 07:10 |
| vikasc | baohua, it is today itself? | 07:11 |
| baohua | yes on Tuesday 15:00 UTC, so it should be about 8 hour later today. | 07:11 |
| vikasc | baohua, thanks for confirming :) | 07:12 |
| baohua | sure :) | 07:12 |
| *** fawadkhaliq has joined #openstack-kuryr | 07:20 | |
| *** vikasc has quit IRC | 07:22 | |
| *** apuimedo has joined #openstack-kuryr | 07:44 | |
| *** salv-orlando has quit IRC | 07:46 | |
| *** fawadkhaliq has quit IRC | 07:49 | |
| *** fawadkhaliq has joined #openstack-kuryr | 07:50 | |
| *** lezbar__ has quit IRC | 08:11 | |
| *** devvesa has joined #openstack-kuryr | 08:18 | |
| openstackgerrit | Baohua Yang proposed openstack/kuryr: Add container connect/disconnect tests to fullstack gate job https://review.openstack.org/265105 | 08:45 |
| *** salv-orlando has joined #openstack-kuryr | 08:47 | |
| *** fawadkhaliq has quit IRC | 08:57 | |
| *** fawadkhaliq has joined #openstack-kuryr | 08:57 | |
| *** salv-orlando has quit IRC | 09:01 | |
| *** salv-orlando has joined #openstack-kuryr | 09:03 | |
| *** lezbar has joined #openstack-kuryr | 09:12 | |
| *** vikasc has joined #openstack-kuryr | 09:12 | |
| openstackgerrit | Baohua Yang proposed openstack/kuryr: Check if the return net list is empty before deleting it https://review.openstack.org/265087 | 09:35 |
| *** fawadkhaliq has quit IRC | 09:39 | |
| *** fawadkhaliq has joined #openstack-kuryr | 09:39 | |
| *** salv-orl_ has joined #openstack-kuryr | 10:06 | |
| *** tfukushima has quit IRC | 10:07 | |
| *** salv-orlando has quit IRC | 10:08 | |
| *** tfukushima has joined #openstack-kuryr | 10:10 | |
| *** tfukushima has quit IRC | 10:22 | |
| *** vikasc has quit IRC | 10:41 | |
| *** salv-orl_ has quit IRC | 10:45 | |
| *** salv-orlando has joined #openstack-kuryr | 11:01 | |
| *** irenab has joined #openstack-kuryr | 11:24 | |
| *** kexiaodong has quit IRC | 11:30 | |
| *** vikasc has joined #openstack-kuryr | 11:33 | |
| *** fawadkhaliq has quit IRC | 11:34 | |
| *** baohua has quit IRC | 12:00 | |
| *** salv-orlando has quit IRC | 12:11 | |
| *** salv-orlando has joined #openstack-kuryr | 12:13 | |
| *** banix has joined #openstack-kuryr | 12:26 | |
| *** banix has quit IRC | 12:28 | |
| *** banix has joined #openstack-kuryr | 12:44 | |
| *** banix has quit IRC | 12:47 | |
| *** salv-orlando has quit IRC | 12:57 | |
| openstackgerrit | Merged openstack/kuryr: Add "sudo" to the instruction for running Kuryr https://review.openstack.org/272370 | 12:58 |
| *** vikasc has quit IRC | 13:00 | |
| *** fawadkhaliq has joined #openstack-kuryr | 13:02 | |
| *** baohua has joined #openstack-kuryr | 13:24 | |
| *** fawadkhaliq has quit IRC | 13:25 | |
| *** baohua_ has joined #openstack-kuryr | 13:26 | |
| *** baohua has quit IRC | 13:29 | |
| *** banix has joined #openstack-kuryr | 13:44 | |
| *** diogogmt has joined #openstack-kuryr | 13:57 | |
| *** salv-orlando has joined #openstack-kuryr | 13:58 | |
| *** salv-orlando has quit IRC | 14:03 | |
| *** apuimedo has quit IRC | 14:04 | |
| *** diogogmt has quit IRC | 14:20 | |
| *** baohua has joined #openstack-kuryr | 14:36 | |
| *** baohua_ has quit IRC | 14:39 | |
| *** fawadkhaliq has joined #openstack-kuryr | 14:49 | |
| *** gsagie has joined #openstack-kuryr | 14:52 | |
| *** salv-orlando has joined #openstack-kuryr | 14:54 | |
| *** salvorl has joined #openstack-kuryr | 14:56 | |
| *** apuimedo has joined #openstack-kuryr | 14:56 | |
| *** salv-orlando has quit IRC | 14:57 | |
| gsagie | Hello all | 14:58 |
| baohua | hi, gal | 14:58 |
| *** vikasc has joined #openstack-kuryr | 14:58 | |
| banix | hi | 14:58 |
| fawadkhaliq | hola | 14:58 |
| vikasc | hi | 14:59 |
| banix | irenab: apuimedo are you around? | 14:59 |
| salvorl | Aloha | 15:00 |
| apuimedo | ლ(°◡°ლ) | 15:00 |
| irenab | hey | 15:00 |
| irenab | apuimedo: nice :-) | 15:00 |
| *** baohua has quit IRC | 15:01 | |
| *** baohua has joined #openstack-kuryr | 15:01 | |
| banix | Shall we get started? | 15:01 |
| apuimedo | +1 | 15:01 |
| banix | So we wanted to discuss the integration with / support of CNI | 15:02 |
| apuimedo | gsagie: banix: do you know how to ask the openstack boot to log it? | 15:02 |
| apuimedo | salvorl: ^^ | 15:02 |
| gsagie | apuimedo: i think everything in this channel is logged | 15:02 |
| banix | i think these are all logged | 15:02 |
| *** baohua_ has joined #openstack-kuryr | 15:02 | |
| banix | including your fancy art work Toni | 15:02 |
| apuimedo | I meant to make it logged like a meeting with action points and all that jazz | 15:02 |
| *** baohua has quit IRC | 15:02 | |
| apuimedo | banix: good. My descendants should know the beauty of ascii art | 15:03 |
| gsagie | thats probably not possible | 15:03 |
| apuimedo | ok | 15:03 |
| banix | #startmeeting kuryr | 15:03 |
| 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:03 |
| openstack | The meeting name has been set to 'kuryr' | 15:03 |
| fawadkhaliq | apuimedo: lol | 15:03 |
| apuimedo | it is alive! | 15:03 |
| gsagie | maybe it is :) | 15:03 |
| apuimedo | :-) | 15:03 |
| apuimedo | banix, you are chair and table | 15:03 |
| apuimedo | set the topics ;-) | 15:03 |
| banix | #chair apuimedo | 15:03 |
| openstack | Current chairs: apuimedo banix | 15:04 |
| apuimedo | darn | 15:04 |
| apuimedo | that happens for talking too much | 15:04 |
| banix | :) | 15:04 |
| fawadkhaliq | good one banix ;-) | 15:04 |
| apuimedo | #topic kubernetes libnetwork usage | 15:04 |
| apuimedo | mmm | 15:04 |
| irenab | apuimedo: not sure about the topic ... | 15:04 |
| apuimedo | seems it doesn't work | 15:04 |
| irenab | its either first orsecond ... | 15:04 |
| apuimedo | well, everybody read it | 15:05 |
| apuimedo | in this topic I would like to go through the current state | 15:05 |
| *** qwebirc16548 has joined #openstack-kuryr | 15:05 | |
| irenab | kube already has CNI support: https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/network/cni | 15:05 |
| irenab | and it seems to be the prefered way to go | 15:05 |
| 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:05 |
| apuimedo | and relying on configuration to plug to a network | 15:06 |
| apuimedo | do we all agree with that? | 15:06 |
| gsagie | i do | 15:06 |
| vikasc | +1 | 15:06 |
| irenab | +1 | 15:06 |
| qwebirc16548 | um, what does that mean exactly? | 15:06 |
| banix | +0.8 | 15:06 |
| fkautz | It's unlikely k8s will support libnetwork at this point | 15:06 |
| qwebirc16548 | I do not see much movement toward libnetwork among the kube community | 15:06 |
| baohua_ | +0.5 | 15:07 |
| qwebirc16548 | If you do not care about k9s load balancers, we already have all that we need from k8s | 15:07 |
| fkautz | Unless something fundamentally changes in either k8s or docker philosophy | 15:07 |
| qwebirc16548 | we can write a CNI plugin that invokes `docker network` to do what is needed. | 15:07 |
| banix | qwebirc16548: that’s what I am wondering if we can do | 15:08 |
| irenab | qwebirc16548: can you elaborate? | 15:08 |
| qwebirc16548 | sure... | 15:08 |
| fawadkhaliq | qwebirc16548: not sure its a straight forward mapping | 15:08 |
| fawadkhaliq | irenab: +1 | 15:08 |
| 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:08 |
| qwebirc16548 | This is assuming it can determine the desired network. | 15:09 |
| apuimedo | qwebirc16548: doing a CNI plugin that calls docker network is still abandoning direct libnetwork ideas | 15:09 |
| qwebirc16548 | I am thinking of a simple scenario with one network per k8s Namespace | 15:09 |
| apuimedo | qwebirc16548: are you Shu Tao? | 15:09 |
| qwebirc16548 | When the CNI plugin invokes `docker network`, this goes through libnetwork. So no abandonment there. | 15:09 |
| *** salv-orlando has joined #openstack-kuryr | 15:10 | |
| qwebirc16548 | No, I am not Shu Tao. But I know him. | 15:10 |
| vikasc | qwebirc16548: namespace maps to tenants in k8s | 15:10 |
| apuimedo | Mike Spreitzer then I bet :P | 15:10 |
| qwebirc16548 | bingo | 15:10 |
| apuimedo | anyway | 15:10 |
| vikasc | qwebirc16548: then one tenant having more networks is very likely | 15:10 |
| qwebirc16548 | I am supposing each tenant gets one network | 15:10 |
| qwebirc16548 | Yes, that's the next level | 15:10 |
| qwebirc16548 | doing that will require more | 15:11 |
| vikasc | qwebirc16548: hmm | 15:11 |
| *** salv-orlando has quit IRC | 15:11 | |
| apuimedo | doing a CNI translation to the current libnetwork driver is still doing a CNI plugin | 15:11 |
| qwebirc16548 | so? | 15:11 |
| *** salv-orlando has joined #openstack-kuryr | 15:11 | |
| apuimedo | so, can we establish that we are doing that before deciding in which manner go? | 15:11 |
| banix | yes, but it will be a simpler one which will be able to utlize our Kuryr plugin | 15:11 |
| qwebirc16548 | I will do it myself if nobody else gets to it sooner | 15:12 |
| *** salvorl has quit IRC | 15:12 | |
| apuimedo | ok, moving on | 15:12 |
| fkautz | i don't think it'll be that simple, but worth looking into | 15:12 |
| gsagie | so you are basically adding lib network support to cabernets, in some way which is probably not optimal but good enough | 15:12 |
| apuimedo | #topic CNI plugin | 15:12 |
| gsagie | kubernetes | 15:12 |
| salv-orlando | gsagie: love that autocorrect | 15:12 |
| qwebirc16548 | BTW I see work in the k8s networking group that will pass more info, so that a tenant can have multiple networks | 15:12 |
| gsagie | :) | 15:13 |
| vikasc | cni plugin takes just two args, ADD and DELETE. To utilize it existing kuryr only way is to refactor kuryr | 15:13 |
| apuimedo | xD | 15:13 |
| apuimedo | qwebirc16548: for the openshift-namespaces | 15:13 |
| apuimedo | I also saw that | 15:13 |
| *** vikasc_ has joined #openstack-kuryr | 15:13 | |
| salv-orlando | vikasc: which I agree, but what is the contributors' opinion on developing and maintaining both plugins? | 15:13 |
| qwebirc16548 | Unfortunately I have been away for a week, wrestling with Ursula | 15:13 |
| apuimedo | alright, so basically we have two approaches | 15:14 |
| banix | vikasc: I think the suggestion is to use the docker (network) API to implement the CNI API | 15:14 |
| qwebirc16548 | I think I want to make a counter-proposal, that keeps tenant = Namespace, but have not written it yet | 15:14 |
| apuimedo | refactor kuryr and have two different frontends, libnetwork and cni | 15:14 |
| apuimedo | or have cni be a translation to libnetwork with a bit of extra configuration/assumptions | 15:14 |
| baohua_ | like this idea | 15:14 |
| vikasc | banix: yes, in tha case we will not be able to leverage any of existing work | 15:14 |
| banix | vikasc: why not? | 15:15 |
| apuimedo | baohua_: which idea? | 15:15 |
| baohua_ | your idea or two front end but one kuryr, should try leverage current kuryr code at most | 15:15 |
| salv-orlando | apuimedo: the latter implies you're assuming CNI will always back docker. | 15:15 |
| fkautz | apuimedo: are you suggesting a side channel with extra info passed to support anything libnetwork doesn't? | 15:15 |
| salv-orlando | now that might true but at least on the table docker's not the only one | 15:15 |
| apuimedo | salv-orlando: well, I'm cheating actually | 15:15 |
| salv-orlando | apuimedo: you're so openstack ;) | 15:16 |
| apuimedo | I actually think that it is not option 1 or option 2 | 15:16 |
| apuimedo | I think it is option 1 for right now. Then make a proper option 2 | 15:16 |
| irenab | apuimedo: can you please identify option 1 and option2, so we can refer during discussion | 15:16 |
| baohua_ | should not wait the decision from k8s team, so start with option #1 | 15:16 |
| salv-orlando | I mean option 2 could be a short term implementation for the CNI plugin | 15:16 |
| salv-orlando | and then we can iterate over it | 15:17 |
| qwebirc16548 | can someone please clarify which is 1 and what is 2? | 15:17 |
| apuimedo | option T -> translate | 15:17 |
| 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 |
| qwebirc16548 | why not? | 15:17 |
| apuimedo | option F -> different frontends | 15:17 |
| baohua_ | option #F can keep the code more clean, and flexible for further possible change. | 15:18 |
| apuimedo | baohua_: agreed | 15:18 |
| 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 |
| fkautz | Having worked on building such a bridge, I agree with vikasc | 15:18 |
| baohua_ | option #T requires assumption they finally get to libnetwork | 15:18 |
| apuimedo | IMO that's the way to go for the future | 15:18 |
| irenab | so option F is to have CNI to call neutron? | 15:18 |
| apuimedo | option T would be something that we use short term an for no longer than the end of the Mitaka cycle | 15:19 |
| apuimedo | irenab: that's right | 15:19 |
| qwebirc16548 | vikasc: why does calling `docker network` CLI not fit into the CNI model? | 15:19 |
| 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:19 |
| 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 |
| fkautz | K8s wrote a blog post on why libnetwork doesn't work for them on their blog | 15:20 |
| vikasc | apuimedo: +1 | 15:20 |
| fkautz | Many of the concerns will apply here | 15:20 |
| vikasc | fkautz: +1 | 15:20 |
| qwebirc16548 | Yes, I read that blog post and agree | 15:20 |
| fkautz | But a lot of it is in who owns what and what gets exposed | 15:20 |
| banix | #link http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-libnetwork.html | 15:20 |
| baohua_ | oh, more concerns now. | 15:20 |
| qwebirc16548 | Both sides have moved on since | 15:20 |
| fkautz | Can't make decisions if you don't have the info | 15:21 |
| irenab | k8s is not Docker specific, so option T will limit | 15:21 |
| fawadkhaliq | irenab: +1 | 15:21 |
| qwebirc16548 | oh, that's newer | 15:21 |
| vikasc | irenab: nice point | 15:21 |
| baohua_ | so we have the same context now | 15:21 |
| 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 |
| banix | so let’s back up for a second if you all agree | 15:21 |
| irenab | can we drop option T ? | 15:22 |
| apuimedo | qwebirc16548: I see value on right now having work on a thin CNI plugin that does network per namespace. | 15:22 |
| apuimedo | as salv-orlando says, a stopgap measure | 15:22 |
| 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 |
| qwebirc16548 | Yes, I suggest starting there and then expanding as both k8s and docker evolve | 15:22 |
| 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 |
| banix | right? | 15:22 |
| vikasc | i would prefer a seperate plugin sharing libs with libnetwork plugin | 15:22 |
| irenab | vikasc: I share same understanding | 15:23 |
| apuimedo | banix: that's right. I never intended kuryr to be just a libnetwork driver, but bringing neutron to containers | 15:23 |
| salv-orlando | vikasc: I think that's attainable at no cost. | 15:23 |
| baohua_ | banix: agree, we should expand more. | 15:23 |
| vikasc | salv-orlando: i too believe so | 15:24 |
| apuimedo | Do we all agree that long term, we see option F as the right one? | 15:24 |
| baohua_ | apuimedo:+1 | 15:24 |
| apuimedo | I'll put my +1 | 15:24 |
| vikasc | +1 | 15:24 |
| banix | apuimedo: yes | 15:24 |
| fkautz | +1 on F | 15:24 |
| fawadkhaliq | apuimedo: +1 yes, until there is one option left ;-) | 15:25 |
| apuimedo | irenab: ^^, gsagie ^^ | 15:25 |
| irenab | +1 | 15:25 |
| gsagie | +1 | 15:25 |
| apuimedo | alright, I think we have good enough support | 15:25 |
| baohua_ | agile decision:) | 15:25 |
| irenab | the question if we start with option F or you still want short term option T? | 15:25 |
| apuimedo | #info The long term goal is to have different frontends for different platforms | 15:25 |
| apuimedo | #topic implementation of a works-now translation layer for Kubernetes (with docker) | 15:26 |
| vikasc | my opinion start with F | 15:26 |
| baohua_ | i suggest start with option #F directly | 15:26 |
| irenab | +1 | 15:26 |
| gsagie | start with option F, we can work in parallel if anyone wants to start working on the T option as well | 15:26 |
| apuimedo | first of all | 15:26 |
| vikasc | gsagie: +1 | 15:26 |
| apuimedo | don't get so hasty with the votes :P | 15:26 |
| irenab | gsagie: agree, it is ortogonal | 15:26 |
| apuimedo | (╯° °）╯彡┻━┻ | 15:27 |
| fkautz | +1 chair flip :p | 15:27 |
| fkautz | I assume that's a bench | 15:27 |
| apuimedo | please qwebirc16548, could you give us more information about the design for the translation layer? | 15:27 |
| qwebirc16548 | sure | 15:27 |
| apuimedo | fkautz: it's a bar stool | 15:27 |
| baohua_ | guangdang~ | 15:27 |
| qwebirc16548 | I am thinking of starting simple, as I said... | 15:27 |
| qwebirc16548 | Actually, in my environment this is all behind another API layer anyway, which makes it easier... | 15:28 |
| qwebirc16548 | With a k8s NS per tenant, and a network per tenant, all not visible to the real client | 15:28 |
| apuimedo | with the level of information that reaches the CNI plugin, qwebirc16548, what is missing for doing the translation? | 15:28 |
| qwebirc16548 | implicit isolation between tenants | 15:28 |
| qwebirc16548 | My current understanding is nothing is lacking for my under-the-covers isolation | 15:28 |
| qwebirc16548 | I can invent a network name based on the Namespace | 15:29 |
| irenab | qwebirc16548: seems you assume specific app deployment use case, right? | 15:29 |
| qwebirc16548 | and away I go. | 15:29 |
| qwebirc16548 | Yes, like I said. | 15:29 |
| irenab | namespace = Tenant? | 15:29 |
| qwebirc16548 | that is, what I said is all that I assume (that I remember right now) | 15:29 |
| qwebirc16548 | yes | 15:29 |
| irenab | one network per Tenant? | 15:30 |
| qwebirc16548 | irenab: yes | 15:30 |
| qwebirc16548 | As I said, my use pattern is implicit isolation between tenants. | 15:30 |
| irenab | qwebirc16548: does it correspondsto the kube-sig-net proposel 2? | 15:30 |
| salv-orlando | qwebirc16548: which is cool. What would be the corresponding topology in openstack? | 15:30 |
| salv-orlando | I ask because we might have to punch holes here and there | 15:31 |
| qwebirc16548 | Have not had time to study those enough yet. Been wrestling with Ursula. | 15:31 |
| irenab | https://docs.google.com/document/d/1W14C03dsBbZi23FN0LmDe1MI0WLV_0-wf_mRxLr2-g4/edit | 15:31 |
| apuimedo | would it be a single network, single subnet per tenant? | 15:31 |
| irenab | it maybe subnet per Node | 15:31 |
| qwebirc16548 | Yes, I think one subnet per network | 15:31 |
| apuimedo | qwebirc16548: what to do with the cluster ips? | 15:32 |
| apuimedo | cause I assume we'd not have kube-proxy running to set iptables redirects for those | 15:32 |
| qwebirc16548 | in k8s speak, "cluster IPs" are the IPs handed out to the containers,right? | 15:32 |
| irenab | to services | 15:32 |
| qwebirc16548 | Like I said, I have a caveat: we do not care about k8s load balancers | 15:33 |
| apuimedo | qwebirc16548: it's an ip that takes you to any of the pods | 15:33 |
| baohua_ | service layer ip | 15:33 |
| apuimedo | in our prototype we use LBaaS for those | 15:33 |
| qwebirc16548 | Oh, right. The terms are cluster IPs (for the hosts), pod IPs, and service IPs. IIRC | 15:33 |
| baohua_ | it's not binding with lb | 15:33 |
| apuimedo | so we had a separate subnet for cluster ips | 15:33 |
| irenab | qwebirc16548: how the service level connectiviy will work without load balancers? | 15:33 |
| fkautz | Wouldn't eliminating load balancers effectively eliminate k8s services? | 15:34 |
| qwebirc16548 | k8s has LBs for services and for ingress resources. | 15:34 |
| baohua_ | the cluster ip is handled by kube-proxy | 15:34 |
| qwebirc16548 | The caveat I said means you don't care about k8s services and ingress resources. | 15:34 |
| *** salv-orlando has quit IRC | 15:34 | |
| irenab | qwebirc16548: so you plan to keep using kube-proxy as is? | 15:34 |
| fkautz | There is a node port for service, but I recall that not being preferred | 15:34 |
| qwebirc16548 | If you want to use those, then you have to think harder. | 15:34 |
| *** salv-orlando has joined #openstack-kuryr | 15:35 | |
| qwebirc16548 | No, I mean a starting level of development that does not support k8s services and ingress resources. | 15:35 |
| qwebirc16548 | that makes kube-proxy irrelevant. | 15:35 |
| qwebirc16548 | If you want to integrate with kube-proxy then you need non-trivial changes in k8s... | 15:36 |
| qwebirc16548 | or maybe lots of Neutron work with FWaaS. | 15:36 |
| qwebirc16548 | I have not finished thinking that through. Been wrestling with Ursula. | 15:36 |
| apuimedo | qwebirc16548: Ursula? | 15:37 |
| qwebirc16548 | we might be able to use FWaaS to do something like what OpenShift did | 15:37 |
| qwebirc16548 | Ursula is ansible to install OpenStack | 15:37 |
| qwebirc16548 | (yet another) | 15:37 |
| apuimedo | ah! | 15:37 |
| apuimedo | no more installers! | 15:38 |
| baohua_ | yet another! | 15:38 |
| irenab | apuimedo: you should have know it ;-) | 15:38 |
| qwebirc16548 | sorry, it has some local currency | 15:38 |
| apuimedo | y=ｰ( ﾟдﾟ)･∵. | 15:38 |
| qwebirc16548 | even though too few people seem to recognize the author that gave us the word "ansible" | 15:38 |
| fkautz | Nothing wrong with long distance communication! | 15:39 |
| fkautz | FTL | 15:39 |
| irenab | so back to kube on kuryr, do we have a plan? | 15:39 |
| 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 |
| apuimedo | irenab: you mean an option T plan | 15:39 |
| qwebirc16548 | Do you guys think FWaaS is up to the task? | 15:39 |
| apuimedo | fawadkhaliq: precisely. I want to set the minimums | 15:40 |
| irenab | fawadkhaliq: +1 on starting with use case | 15:40 |
| salv-orlando | irenab: idk it seems to me the plan is to wait for qwebirc16548 to finish his fight with Ursula. | 15:40 |
| fawadkhaliq | qwebirc16548: lol nope | 15:40 |
| qwebirc16548 | If so then I think we can do a stop-gap that uses FWaaS in a pattern like OpenShift did. | 15:40 |
| irenab | salv-orlando: :-) | 15:40 |
| vikasc | lol | 15:40 |
| apuimedo | FWaaS as a requirement is a bit of a non-starter | 15:40 |
| apuimedo | I'd rather rely on other primitives | 15:40 |
| fawadkhaliq | exactly | 15:40 |
| fkautz | the load balancers in open shift is a userspace app, we could use it here maybe? | 15:40 |
| irenab | security groups? | 15:40 |
| apuimedo | fkautz: LBaaS and security groups should get option T a long way | 15:41 |
| qwebirc16548 | I think it could be done with SGs, but it's kinda ugly | 15:41 |
| qwebirc16548 | My deepest worry about SGs is two: | 15:41 |
| apuimedo | for that, we should probably make kuryr let you chose sg finally :P | 15:41 |
| qwebirc16548 | 1 is robustness, 2 is performance of control plane, 3 is performance of data plane | 15:41 |
| fkautz | in the long run, I think LBaaS through neutron or another means is best :) | 15:41 |
| apuimedo | cause the libnetwork driver still does not let you | 15:41 |
| fkautz | User space packet copying will eventually affect perf | 15:42 |
| 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 |
| 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:42 |
| qwebirc16548 | salv-orlando: I am discussing worries about using SGs to get isolation between tenants | 15:43 |
| qwebirc16548 | when kube-proxy is being sued. | 15:43 |
| qwebirc16548 | used. | 15:43 |
| apuimedo | I'm not familiar enough with the reference impl to comment | 15:43 |
| salv-orlando | qwebirc16548: service-2-pod networking then. ok. | 15:43 |
| irenab | In my opinion we should try to start aligned with kube-sig-net proposal, probably the most basic case | 15:44 |
| 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 |
| qwebirc16548 | proxies | 15:44 |
| apuimedo | but, couldn't we start working on the kube-proxy alternative for option F and option T could leverage it? | 15:44 |
| qwebirc16548 | working on a kube-proxy involves k8s changes... | 15:45 |
| qwebirc16548 | which are being discussed there. | 15:45 |
| apuimedo | as in, no kube-proxy, but something that makes API calls to Neutron | 15:45 |
| salv-orlando | apuimedo: that is a viable option but you might want to discuss with k8s upstream too | 15:45 |
| apuimedo | salv-orlando: I was thinking pluggability at the k8s API server level actually | 15:45 |
| apuimedo | I haven't checked if that requires k8s changes yet | 15:46 |
| fkautz | apuimedo: right now is the best time to bring that up | 15:46 |
| apuimedo | fkautz: you are completely right | 15:46 |
| fkautz | K8s is talking about long term shape of networking | 15:46 |
| fkautz | Thursday at I think 5pm est is a meeting for k8s | 15:46 |
| fkautz | Definitely join it | 15:46 |
| salv-orlando | apuimedo: pluggability in the kube-proxy so far is an if statement where one branch loads the deprecated userspace LB | 15:46 |
| 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:46 |
| apuimedo | imho, and with having read the API server | 15:47 |
| salv-orlando | it's wedds 2PM PST for this week | 15:47 |
| fkautz | Oh, Wednesday this week, good to know. :x | 15:47 |
| apuimedo | we (k8s integrators) could get a lot of flexibility out of being able to create entities from the API objects | 15:47 |
| apuimedo | and then have the CNI layer just plug into those | 15:47 |
| irenab | apuimedo: +1 | 15:48 |
| apuimedo | (also would help with latency elimination going all the way to neutron and beyond for some things) | 15:48 |
| irenab | apuimedo: so CNI mostly for binding? | 15:49 |
| apuimedo | that's one way | 15:49 |
| apuimedo | banix: I don't see you around ;-) | 15:49 |
| irenab | I think it is expected tocall IPAM driver too | 15:49 |
| banix | apuimedo: Tables don’t talk much | 15:50 |
| apuimedo | irenab: sure. A part of the IPAM would be at CNI level | 15:50 |
| *** baohua_ has quit IRC | 15:50 | |
| irenab | apuimedo: we have 10 mins left. Can you get some summary on next steps? | 15:51 |
| apuimedo | in my mind we need either that, or we need to contribute to the kube-proxy pluggability significantly | 15:51 |
| 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:51 |
| qwebirc16548 | I would like to see a long term design, aligned with ks8 net sig thinking | 15:52 |
| salv-orlando | apuimedo: well... you might want to consider running an os-kube-proxy | 15:52 |
| qwebirc16548 | That requires some thinking and writing on both sides | 15:52 |
| apuimedo | Also, we probably will need somewhere to perform the translations of "series of `allofrom`" to Neutron entities | 15:52 |
| salv-orlando | at the end of the day k8s components are all loosely coupled bits that communicated with the API server | 15:53 |
| qwebirc16548 | I am not quite ready to spout the design now. | 15:53 |
| fkautz | I agree entirely with qwebirc16548's comment on alignment | 15:53 |
| salv-orlando | neither am I - I am just saying let's not constraint ourselves into anything and keep all options on the table | 15:53 |
| apuimedo | I agree with that | 15:54 |
| apuimedo | Kuryr set out to work as a bridge with the communities | 15:54 |
| apuimedo | and we have to be more present in the k8s community right now | 15:54 |
| apuimedo | that said | 15:54 |
| 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:55 |
| 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 |
| irenab | apuimedo: I think we should decide on the kuryr components/libs | 15:56 |
| 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:56 |
| apuimedo | irenab: ? | 15:57 |
| irenab | we may need some API watcher , which does not fit well into kurrent on node kuryr service | 15:57 |
| apuimedo | what I'd like to do, as it appears simpler in my mind is to first | 15:57 |
| apuimedo | 1.- Take a few Kubernetes typical usages and redraw them using Neutron components | 15:58 |
| apuimedo | 2. find the best places in k8s to create them | 15:58 |
| apuimedo | 3. Make those possible in k8s if they are not or settle for good approximations | 15:58 |
| apuimedo | 2-3 need quite a bit of participation upstream | 15:59 |
| apuimedo | qwebirc16548: Do you want to replicate the OpenShift networking model or something a bit different? | 16:00 |
| irenab | qwebirc16548: any link you can share on openShift network model? | 16:00 |
| 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:00 |
| qwebirc16548 | I do not have a link. I can write very briefly here, then have to go to next mtg. | 16:01 |
| qwebirc16548 | Each tenant has one private network | 16:01 |
| qwebirc16548 | each VM/container can send to any other on the private network (subject to SGs) and to services | 16:01 |
| qwebirc16548 | I am not sure which ones | 16:01 |
| qwebirc16548 | Mainly tenant's own services, I suppose | 16:01 |
| qwebirc16548 | Later | 16:02 |
| *** qwebirc16548 has quit IRC | 16:02 | |
| fawadkhaliq | irenab: https://docs.openshift.com/enterprise/3.0/architecture/additional_concepts/networking.html | 16:02 |
| irenab | thanks | 16:02 |
| apuimedo | #link https://docs.openshift.com/enterprise/3.0/architecture/additional_concepts/networking.html | 16:02 |
| irenab | I would say we need to identigy the use case to support first | 16:03 |
| fawadkhaliq | irenab: +1 | 16:03 |
| fkautz | and unfortunately, that is still a moving target, but I think we have enough now that we can approximate | 16:03 |
| apuimedo | fkautz: it is a moving target indeed. But we can help moving it | 16:04 |
| fkautz | +1 | 16:04 |
| apuimedo | if we agree on what we want it to be | 16:04 |
| fawadkhaliq | fkautz: agree. we can plan for it | 16:04 |
| fawadkhaliq | apuimedo: exactly | 16:04 |
| apuimedo | that's why I said I wanted to translate deployment configurations into neutron primitives | 16:04 |
| *** vikasc_ has quit IRC | 16:04 | |
| apuimedo | agree on those | 16:04 |
| apuimedo | and then help move the k8s target to make those possible | 16:05 |
| irenab | apuimedo: this is right, we need to identify the scenario we want to support | 16:05 |
| apuimedo | so far it seems like they are still planning for different modes | 16:05 |
| irenab | shall we start some use cases doc/etherpad? | 16:05 |
| apuimedo | one where there is full isolation | 16:05 |
| banix | apuimedo: time for a few action items | 16:06 |
| apuimedo | and every connectivity is defined via allowfrom | 16:06 |
| vikasc | irenab: can we use existing k8s etherpad? | 16:06 |
| irenab | lets add a section there | 16:06 |
| apuimedo | and another mode where there is connectivity between pods but services require the allowfrom | 16:06 |
| apuimedo | banix: agreed | 16:06 |
| *** salv-orl_ has joined #openstack-kuryr | 16:06 | |
| fkautz | Link? | 16:07 |
| irenab | vikasc: we already have use cases section :-) | 16:07 |
| irenab | https://etherpad.openstack.org/p/kuryr_k8s | 16:07 |
| irenab | need to add content | 16:07 |
| fkautz | Thanks, I'll contribute to it as well | 16:07 |
| fawadkhaliq | #link https://etherpad.openstack.org/p/kuryr_k8s | 16:07 |
| vikasc | irenab: lets do :) | 16:07 |
| apuimedo | #action everybody come to next monday meeting with a translation of deployments into neutron primitives | 16:07 |
| apuimedo | please put a link to the diagram in the etherpad | 16:07 |
| irenab | apuimedo: so we can have few to chose from :-) ? | 16:08 |
| apuimedo | irenab: or rather to converge | 16:08 |
| irenab | +1 | 16:08 |
| apuimedo | who can make tomorrow's meeting with k8s-sig-net? | 16:08 |
| fkautz | I will be there | 16:08 |
| banix | i can | 16:08 |
| vikasc | vikasc: i will also attend | 16:09 |
| apuimedo | I'll do my best to make it too | 16:09 |
| irenab | same here | 16:09 |
| fawadkhaliq | will try | 16:09 |
| *** salv-orlando has quit IRC | 16:09 | |
| 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 |
| apuimedo | fawadkhaliq: if you can try as well even better :-) | 16:09 |
| fawadkhaliq | apuimedo: will do :-) | 16:10 |
| apuimedo | banix: do you think qwebirc16548 could come to next kuryr meeting with a bit more defined plan for option T | 16:10 |
| apuimedo | so we can decide on it | 16:10 |
| *** devvesa has quit IRC | 16:10 | |
| 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 |
| banix | apuimedo: will talk to him but you know Ursala is pretty merciless ;) | 16:11 |
| apuimedo | ¯\_(ツ)_/¯ | 16:11 |
| banix | i agree | 16:11 |
| fawadkhaliq | rofl | 16:11 |
| apuimedo | installers are a plague | 16:11 |
| apuimedo | anyway | 16:11 |
| 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 |
| apuimedo | and if we can make it for Mitaka | 16:12 |
| apuimedo | banix: irenab gsagie vikasc fawadkhaliq fkautz: any action I am missing? | 16:13 |
| 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 |
| apuimedo | I'd rather have it in the usual slot next week. If we see that the meetings start to overflow | 16:13 |
| apuimedo | we can make a kuryr-sig-k8s | 16:13 |
| apuimedo | :P | 16:13 |
| irenab | banix: I think we agreed to adduse cases in the etherpad | 16:13 |
| banix | yes | 16:13 |
| fawadkhaliq | apuimedo: nope. looks good. it's a good start. | 16:13 |
| apuimedo | going once | 16:13 |
| apuimedo | •_•) | 16:14 |
| banix | #endmeeting | 16:14 |
| openstack | Meeting ended Tue Jan 26 16:14:14 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:14 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-26-15.03.html | 16:14 |
| apuimedo | going twice | 16:14 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-26-15.03.txt | 16:14 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-26-15.03.log.html | 16:14 |
| banix | table interrupted the chair! :) | 16:14 |
| irenab | seems table takes actions :-) | 16:14 |
| apuimedo | ( •_•)>⌐■-■, | 16:14 |
| fawadkhaliq | trickster..gone already | 16:14 |
| fawadkhaliq | lol | 16:14 |
| apuimedo | (⌐■_■) | 16:14 |
| apuimedo | darn, that didn't make it into the log | 16:14 |
| apuimedo | :P | 16:14 |
| apuimedo | banix: now I am sad | 16:14 |
| apuimedo | I'll have to fix my alias | 16:15 |
| banix | sad panda kind of sad? | 16:15 |
| irenab | apuimedo: banix : thanks for leading the meeting | 16:15 |
| apuimedo | indeed | 16:15 |
| irenab | bye | 16:15 |
| apuimedo | banix: I'll have to go to kfc to cheer up | 16:15 |
| banix | bye all | 16:15 |
| banix | :) | 16:15 |
| fawadkhaliq | bye | 16:15 |
| fawadkhaliq | apuimedo: take it easy there ;-) | 16:15 |
| apuimedo | fawadkhaliq: I can't promise anything | 16:16 |
| apuimedo | thank you all for joining! | 16:16 |
| apuimedo | it was a very nice meeting | 16:16 |
| gsagie | I wish we had KFC in israel.. | 16:17 |
| gsagie | so i could cheer up | 16:17 |
| fawadkhaliq | gsagie: whaat | 16:17 |
| gsagie | :) | 16:18 |
| fawadkhaliq | apuimedo: send some over to gsagie man, we need the entire team happy :-) | 16:18 |
| apuimedo | gsagie: there is no KFC there?! | 16:18 |
| apuimedo | that's terrible | 16:18 |
| gsagie | nope | 16:19 |
| apuimedo | I only knew Myanmar doesn't have it | 16:19 |
| apuimedo | you are in a very bad list now | 16:19 |
| gsagie | heh yes | 16:19 |
| *** fawadkhaliq has quit IRC | 16:20 | |
| *** vikasc has quit IRC | 16:22 | |
| *** devvesa has joined #openstack-kuryr | 16:26 | |
| *** diogogmt has joined #openstack-kuryr | 16:26 | |
| *** devvesa has quit IRC | 16:31 | |
| *** apuimedo_ has joined #openstack-kuryr | 16:40 | |
| *** apuimedo has quit IRC | 16:40 | |
| *** gsagie has quit IRC | 16:41 | |
| *** gsagie has joined #openstack-kuryr | 16:50 | |
| *** apuimedo_ has quit IRC | 16:57 | |
| *** fawadkhaliq has joined #openstack-kuryr | 16:57 | |
| *** fawadk has joined #openstack-kuryr | 17:03 | |
| *** diogogmt_ has joined #openstack-kuryr | 17:04 | |
| *** banix_ has joined #openstack-kuryr | 17:05 | |
| *** fawadkhaliq has quit IRC | 17:07 | |
| *** diogogmt has quit IRC | 17:07 | |
| *** banix has quit IRC | 17:07 | |
| *** diogogmt_ is now known as diogogmt | 17:07 | |
| *** banix_ is now known as banix | 17:07 | |
| *** openstackgerrit has quit IRC | 17:17 | |
| *** openstackgerrit has joined #openstack-kuryr | 17:17 | |
| gsagie | banix, irenab: https://github.com/contiv/netplugin/tree/master/mgmtfn/k8splugin | 17:23 |
| *** diogogmt has quit IRC | 17:44 | |
| *** diogogmt has joined #openstack-kuryr | 17:58 | |
| *** fawadk has quit IRC | 18:24 | |
| *** gsagie has quit IRC | 18:33 | |
| *** diogogmt has quit IRC | 19:35 | |
| *** salv-orl_ has quit IRC | 19:46 | |
| *** diogogmt has joined #openstack-kuryr | 19:49 | |
| *** salv-orlando has joined #openstack-kuryr | 20:47 | |
| *** salv-orlando has quit IRC | 21:00 | |
| *** salv-orlando has joined #openstack-kuryr | 21:30 | |
| *** banix has quit IRC | 21:48 | |
| *** salv-orl_ has joined #openstack-kuryr | 22:06 | |
| *** salv-orlando has quit IRC | 22:09 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!