| *** yamamoto_ has quit IRC | 00:12 | |
| *** openstack has joined #openstack-kuryr | 00:23 | |
| *** fawadkhaliq has quit IRC | 00:30 | |
| *** fawadkhaliq has joined #openstack-kuryr | 00:33 | |
| *** fawadkhaliq has quit IRC | 00:58 | |
| *** fawadkhaliq has joined #openstack-kuryr | 01:02 | |
| *** fawadkhaliq has quit IRC | 01:02 | |
| *** fawadkhaliq has joined #openstack-kuryr | 01:06 | |
| *** fawadkhaliq has quit IRC | 01:06 | |
| *** banix has quit IRC | 01:10 | |
| *** yamamoto has joined #openstack-kuryr | 01:13 | |
| *** fawadkhaliq has joined #openstack-kuryr | 01:18 | |
| *** fawadkhaliq has quit IRC | 01:19 | |
| *** yamamoto has quit IRC | 01:20 | |
| *** fawadkhaliq has joined #openstack-kuryr | 01:30 | |
| *** fawadkhaliq has quit IRC | 01:31 | |
| *** fawadkhaliq has joined #openstack-kuryr | 01:42 | |
| *** banix has joined #openstack-kuryr | 01:45 | |
| *** fawadkhaliq has quit IRC | 01:51 | |
| *** fawadkhaliq has joined #openstack-kuryr | 01:51 | |
| *** tfukushima has joined #openstack-kuryr | 01:57 | |
| *** tfukushima has quit IRC | 01:58 | |
| *** fawadkhaliq has quit IRC | 02:06 | |
| *** yamamoto_ has joined #openstack-kuryr | 02:19 | |
| *** fawadkhaliq has joined #openstack-kuryr | 02:25 | |
| *** fawadkhaliq has quit IRC | 02:32 | |
| *** tfukushima has joined #openstack-kuryr | 03:02 | |
| *** tfukushima has quit IRC | 03:04 | |
| *** yuanying has quit IRC | 03:20 | |
| *** yamamoto_ has quit IRC | 03:25 | |
| *** tfukushima has joined #openstack-kuryr | 03:50 | |
| *** tfukushima has quit IRC | 03:52 | |
| *** yamamoto_ has joined #openstack-kuryr | 04:06 | |
| *** yuanying has joined #openstack-kuryr | 04:07 | |
| *** tfukushima has joined #openstack-kuryr | 04:07 | |
| *** fawadkhaliq has joined #openstack-kuryr | 04:14 | |
| *** banix has quit IRC | 04:24 | |
| *** tfukushima has quit IRC | 04:43 | |
| *** tfukushima has joined #openstack-kuryr | 05:23 | |
| *** fawadkhaliq has quit IRC | 05:42 | |
| *** fawadkhaliq has joined #openstack-kuryr | 05:43 | |
| *** fawadkhaliq has quit IRC | 05:52 | |
| *** fawadkhaliq has joined #openstack-kuryr | 05:53 | |
| *** fawadkhaliq has quit IRC | 07:03 | |
| *** fawadkhaliq has joined #openstack-kuryr | 07:04 | |
| *** fawadkhaliq has quit IRC | 07:25 | |
| *** fawadkhaliq has joined #openstack-kuryr | 07:26 | |
| *** fawadkhaliq has quit IRC | 07:26 | |
| *** fawadkhaliq has joined #openstack-kuryr | 07:27 | |
| *** wanghua has joined #openstack-kuryr | 07:29 | |
| *** oanson has joined #openstack-kuryr | 08:37 | |
| *** salv-orlando has joined #openstack-kuryr | 09:11 | |
| *** tfukushima has quit IRC | 09:39 | |
| *** tfukushima has joined #openstack-kuryr | 09:48 | |
| *** openstackgerrit has quit IRC | 09:53 | |
| *** openstackgerrit_ is now known as openstackgerrit | 09:53 | |
| *** openstackgerrit has quit IRC | 09:53 | |
| *** openstackgerrit_ has joined #openstack-kuryr | 09:53 | |
| *** openstackgerrit has joined #openstack-kuryr | 09:54 | |
| *** openstackgerrit has quit IRC | 09:54 | |
| *** openstackgerrit_ is now known as openstackgerrit | 09:54 | |
| *** openstackgerrit_ has joined #openstack-kuryr | 09:54 | |
| *** openstackgerrit has quit IRC | 09:55 | |
| *** openstackgerrit has joined #openstack-kuryr | 09:55 | |
| *** salv-orlando has quit IRC | 10:56 | |
| *** yamamoto_ has quit IRC | 11:05 | |
| *** tfukushima has quit IRC | 11:12 | |
| *** tfukushima has joined #openstack-kuryr | 11:13 | |
| *** tfukushima has quit IRC | 11:13 | |
| *** openstackgerrit has quit IRC | 11:18 | |
| *** openstackgerrit has joined #openstack-kuryr | 11:18 | |
| *** salv-orlando has joined #openstack-kuryr | 11:57 | |
| *** yamamoto has joined #openstack-kuryr | 12:08 | |
| *** salv-orlando has quit IRC | 12:28 | |
| *** fawadkhaliq has quit IRC | 12:31 | |
| *** yamamoto has quit IRC | 12:45 | |
| *** yamamoto has joined #openstack-kuryr | 12:52 | |
| *** fawadkhaliq has joined #openstack-kuryr | 13:29 | |
| *** salv-orlando has joined #openstack-kuryr | 13:29 | |
| *** gsagie has quit IRC | 13:39 | |
| *** salv-orlando has quit IRC | 13:40 | |
| *** yamamoto has quit IRC | 13:43 | |
| *** banix has joined #openstack-kuryr | 13:55 | |
| *** banix has quit IRC | 14:09 | |
| *** yamamoto has joined #openstack-kuryr | 14:12 | |
| *** banix has joined #openstack-kuryr | 14:12 | |
| *** tfukushima has joined #openstack-kuryr | 14:14 | |
| *** salv-orlando has joined #openstack-kuryr | 14:15 | |
| *** mspreitz has joined #openstack-kuryr | 14:21 | |
| *** vikasc has joined #openstack-kuryr | 14:26 | |
| *** apuimedo has joined #openstack-kuryr | 14:29 | |
| *** fawadkhaliq has quit IRC | 14:30 | |
| *** fawadkhaliq has joined #openstack-kuryr | 14:30 | |
| mspreitz | we are waiting for Gal Sagie now, right? | 14:30 |
|---|---|---|
| apuimedo | #startmeeting k8s integration discussion | 14:30 |
| openstack | Meeting started Wed Mar 16 14:30:39 2016 UTC and is due to finish in 60 minutes. The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:30 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:30 |
| openstack | The meeting name has been set to 'k8s_integration_discussion' | 14:30 |
| irenab | Gal is not able to join today | 14:30 |
| apuimedo | Who is here for the meeting? | 14:30 |
| mspreitz | o/ | 14:30 |
| irenab | I am | 14:31 |
| salv-orlando | I am | 14:31 |
| apuimedo | banix? | 14:31 |
| tfukushima | I happen to be here. | 14:31 |
| fawadkhaliq | morning | 14:31 |
| banix | o/ | 14:31 |
| vikasc | o/ | 14:31 |
| salv-orlando | fawadkhaliq: good for you you moved to DST this week | 14:31 |
| apuimedo | vikasc: nice to see you after some time :-) | 14:31 |
| fawadkhaliq | salv-orlando: yes :) | 14:32 |
| apuimedo | #info irenab mspreitz salv-orlando tfukushima, fawadkhaliq banix vikasc and apuimedo present | 14:32 |
| vikasc | apuimedo: thanks apuimedo, was not well !! | 14:32 |
| apuimedo | vikasc: hope you are very well now :-) | 14:33 |
| vikasc | apuimedo: perfect now | 14:33 |
| vikasc | :) | 14:33 |
| apuimedo | We are here to discuss today the status of the two efforts that were proposed in the previous of these meetings | 14:33 |
| apuimedo | One effort was the CNI->CNM translation integration. Lead by mspreitz | 14:33 |
| apuimedo | The other one the direct k8s/cni support led by irena | 14:34 |
| apuimedo | #topic direct CNI->CNM translation | 14:34 |
| apuimedo | #link https://github.com/kubernetes/kubernetes/pull/21956/commits/06ad511c055e8a9eb8cadf0e128d413ccdcdf64f | 14:34 |
| apuimedo | #link https://review.openstack.org/#/c/290172/ | 14:35 |
| apuimedo | Above are the commit that mspreitz submitted to k8s upstream and the devref he has submitted here for review | 14:35 |
| apuimedo | mspreitz: if you maybe want to give a short summary of the status? | 14:36 |
| mspreitz | that commit is just T0; the devref is T1 and T2 | 14:36 |
| mspreitz | sure | 14:36 |
| apuimedo | thanks | 14:36 |
| mspreitz | The k8s PR is a very basic CNI plugin, but it covers most of what we need in the no-policy case. | 14:36 |
| salv-orlando | mspreitz: the thing you pushed for k8s... is it just a sample about how to CNI or do you have other plands? | 14:36 |
| salv-orlando | *plans | 14:36 |
| mspreitz | The devref for T1 is about how to implement the Network Policy proposal from the k8s network SIG, still single-tenant | 14:37 |
| mspreitz | The devref for T2 adds multi-tenancy. | 14:37 |
| mspreitz | The T0 plugin I have tested, it is very simple and does what it is intended to do. | 14:37 |
| mspreitz | I have started implementing T1, but am just getting started. | 14:37 |
| apuimedo | alright. Let's go T by T | 14:38 |
| mspreitz | sure | 14:38 |
| salv-orlando | apuimedo: and eventually we'll get to Mr T | 14:38 |
| apuimedo | I pity the fool! | 14:38 |
| mspreitz | So has anybody looked at the T0 plugin | 14:39 |
| mspreitz | ? | 14:39 |
| apuimedo | T0 gets the Neutron network from the cni config file | 14:39 |
| mspreitz | yes | 14:39 |
| apuimedo | then talks to neutron to get a port and returns the IP information as per the CNI contract, from what I saw | 14:40 |
| apuimedo | (through libnetwork connect and disconnect) | 14:40 |
| mspreitz | yes, but not directly. It goes through Docker's network CLI | 14:40 |
| mspreitz | exactly | 14:40 |
| mspreitz | More precisely, it goes through `docker network` to the Kuryr libnetwork plugin | 14:40 |
| salv-orlando | apuimedo, mspreitz: it could then work regardless of neutron | 14:40 |
| mspreitz | yes, the T0 plugin is not actually specific to Kuryr | 14:41 |
| apuimedo | salv-orlando: yes. It is just CNI to CNM | 14:41 |
| mspreitz | it works with any Docker network | 14:41 |
| salv-orlando | yeah, makes sense | 14:41 |
| apuimedo | the only limitation, is that is pod level only, so you don't get service stuff | 14:41 |
| apuimedo | That kind of information does not reach CNI presently | 14:42 |
| mspreitz | The idea of T0 is that this is within the k8s networking context... | 14:42 |
| mspreitz | in which every pod and every host can open a connection to any pod. | 14:42 |
| mspreitz | Thus the existing k8s service load balancers work. | 14:42 |
| irenab | so you assume kube-proxy to take care of the service? | 14:42 |
| apuimedo | mspreitz: sure. I get that. I'm just giving information about what kind of gaps it fills and which it does not | 14:43 |
| apuimedo | irenab: yes. It relies on kube-proxy | 14:43 |
| mspreitz | The T0 plugin assumes that something else has completed the functional requirements: that is, enabled every host to open connections to every pod. | 14:43 |
| mspreitz | As discussed in the T1 devref, this can be accomplished in neutron by adding some routes. | 14:43 |
| apuimedo | so the vendors that implement T0 must have the network configured for the container accessible from the hosts (for example it being a public external network) | 14:44 |
| mspreitz | irenab: in short, I am confirming that I am talking about enabling kube-proxy to work. | 14:44 |
| mspreitz | apuimedo: right | 14:44 |
| apuimedo | ;-) | 14:44 |
| irenab | mspreitz: how IPAM is done? | 14:44 |
| mspreitz | irenab: however the Docker network does it | 14:45 |
| mspreitz | the T0 plugin is just a piece of glue | 14:45 |
| apuimedo | irenab: cni -> libnetwork -> kuryr ipam -> neutron | 14:45 |
| irenab | so subnet per host is not assumed | 14:45 |
| mspreitz | right | 14:45 |
| apuimedo | irenab: no | 14:45 |
| irenab | this is the comment that is discussed over the spec I pushed | 14:45 |
| mspreitz | irenab: I am not sure I follow. But I have not read the most recent comments. | 14:46 |
| mspreitz | yet | 14:46 |
| apuimedo | alright. Did everybody follow properly the assumptions, preconditions and workflow of T0? | 14:46 |
| irenab | yes, CNI for libnetwork | 14:47 |
| banix | yes | 14:47 |
| irenab | rest is native k8s | 14:47 |
| apuimedo | salv-orlando: tfukushima: ? | 14:47 |
| fawadkhaliq | yes | 14:47 |
| apuimedo | vikasc: ? | 14:47 |
| vikasc | yes | 14:47 |
| tfukushima | Yes. | 14:48 |
| apuimedo | alright. Let's move on to T1 | 14:48 |
| apuimedo | mspreitz: short intro, please | 14:48 |
| mspreitz | sure... | 14:48 |
| mspreitz | The k8s network SIG has been defining a new concept in k8s called "network policy", by which a k8s user can declare what connectivity is allowed. | 14:49 |
| mspreitz | It is deliberately more abstract than Neutron. Rather than talking about networks, subnets, firewalls, routes, and so on, it talks about which endpoints can open connections to which endpoints, that's all | 14:50 |
| mspreitz | it is designed, however, in a way that maps pretty directly onto Neutron security groups. | 14:50 |
| mspreitz | Both are additive sets of rules about allowed connections. | 14:50 |
| mspreitz | So the T1 devref specifies the mapping from network policies to Neutron security groups. | 14:50 |
| mspreitz | end of intro. | 14:50 |
| apuimedo | thanks mspreitz | 14:51 |
| fawadkhaliq | mspreitz: by design of k8s "network policy", the network definition etc still has to be define separately, right? or you are saying this is policy based type of networking, where everything is just taken care of my magic? | 14:51 |
| fawadkhaliq | s/my/by/ | 14:51 |
| mspreitz | No magic here | 14:51 |
| mspreitz | It is a matter of deliberate abstraction. | 14:52 |
| apuimedo | mspreitz: IIUC, to what you have in T0, you'd add a policy agent that watches the API for policy needs and creates SGs | 14:52 |
| irenab | mspreitz: I experimented with mappings of policy ingress to security groups and ended up with pretty same understanding as you | 14:52 |
| mspreitz | The idea is that the k8s user *never* talks about networks. He only talks about connectivity. | 14:52 |
| fawadkhaliq | mspreitz: okay. makes sense. | 14:52 |
| salv-orlando | frankly talking about network intended as "domain where things can connect each other" is non-relevant to what we have today because kubernetes does everything it can to ensure there could be only one of these things | 14:53 |
| mspreitz | It is up to the implementation to map allowed connectivity into lower level details. | 14:53 |
| salv-orlando | but the mapping between security groups and network policies make quite sense | 14:53 |
| mspreitz | I think the obvious choice is that a k8s namespace equates to a Neutron virtual ethernet. | 14:54 |
| salv-orlando | frankly my understanding is that you just need that one additional step due to translating pods and namespaces into source ips | 14:54 |
| irenab | for me it looks very much as GBP talking about App policies, while network policy is not the app concern | 14:54 |
| mspreitz | because in k8s network policy there is no allowed non-IP traffic between k8s namespaces. | 14:55 |
| apuimedo | mspreitz: I am not 100% convinced about the statement that k8s implicitly forbids non-IP traffic. IIRC it was said that it was up to the network plugin | 14:55 |
| fawadkhaliq | irenab: exactly my thoughts | 14:55 |
| apuimedo | but that it was common to do it like that | 14:55 |
| mspreitz | "GBP"? | 14:55 |
| salv-orlando | mspreitz: you have to make that choice in the plugin or any logic which sits outside of kubernetes anyway | 14:55 |
| salv-orlando | yeah the british pount | 14:55 |
| fawadkhaliq | mspreitz: GPB->group based policy | 14:55 |
| salv-orlando | it's roughly 1.27 to the europ | 14:55 |
| mspreitz | I think the decision that k8s network policy forbids non-IP traffic between namespaces and says nothing else about non-IP traffic was agreed in a meeting and never written down. | 14:56 |
| banix | let us not talk about GBP. it still hurts. | 14:56 |
| apuimedo | hey, for the young people, what is GBP? | 14:56 |
| irenab | banix: conceptually :-) | 14:56 |
| salv-orlando | why banix did you moved all your savings into the UK before the dollar strenghtened? :) | 14:56 |
| irenab | group based policy | 14:56 |
| apuimedo | (young to the OSt world) | 14:56 |
| fawadkhaliq | banix: :-) | 14:57 |
| banix | :) | 14:57 |
| apuimedo | you should put it in CZK | 14:57 |
| apuimedo | eastern currency best currency | 14:57 |
| apuimedo | (I lost 10% of my money just so that car makers would be happy...) | 14:57 |
| salv-orlando | Group Based Policies was the moment in which neutron community was very close to break in two | 14:57 |
| banix | as someone said, they are devaluing their currency, we are going to stop it, and make them pay for it! | 14:58 |
| salv-orlando | but I don't think this is relevant at all here | 14:58 |
| mspreitz | So we are agreed to ignore group based policy here and now? | 14:58 |
| fawadkhaliq | mspreitz: yes, that was a just a comment :) | 14:58 |
| mspreitz | OK. | 14:58 |
| mspreitz | So getting back to T1... | 14:58 |
| apuimedo | mspreitz: from T1 devref | 14:58 |
| mspreitz | There is an unwritten detail about non-IP traffic that implies k8s namespace = neutron virtual ethernet. | 14:59 |
| apuimedo | I missed what puts the ports of a namespace into different SGs. I take it that it is the policy agent | 14:59 |
| mspreitz | apuimedo: policy agent ensures that is eventually consistent. CNI plugin speeds that up. | 14:59 |
| apuimedo | but the algorithm for creating needed sgs and doing the assignment once the nets and ports are created was a bit fuzzy for me | 14:59 |
| apuimedo | mspreitz: it checks the thirdparty resources for networkpolicy elements? | 15:00 |
| mspreitz | yes | 15:00 |
| apuimedo | *does it | 15:00 |
| mspreitz | it monitors, keeping an in-memory cache | 15:00 |
| mspreitz | keeping the cache up to date, incrementally responding to changes, after startup transient. | 15:01 |
| apuimedo | so the burden of converting the allowfrom (ingress and egress) into networkpolicies is on the k8s api, then, right? | 15:01 |
| mspreitz | no, allowFrom is part of the syntax of a network policy | 15:01 |
| salv-orlando | apuimedo: I'm not sure, but it would be great if the api server did somehting like that | 15:01 |
| banix | allowfrom is the policy | 15:01 |
| salv-orlando | but I'm afraid the burdgen is on the agent | 15:02 |
| irenab | apuimedo: watcher of policy that transaltes to SGs and assigns ports | 15:02 |
| mspreitz | The k8s api server just stores the network policies and provides events about their changes. | 15:02 |
| mspreitz | It is all up to us to interpret the policies | 15:02 |
| apuimedo | banix: mspreitz: if my understanding is right. There is several levels of policy and overrides that you can have, service, pod and namespace | 15:02 |
| apuimedo | is the current policy object a frankestein with overrides for each definition? | 15:03 |
| mspreitz | apuimedo: actually it is deliberately simple, no overrides | 15:03 |
| apuimedo | *frankenstein | 15:03 |
| mspreitz | it is only additive, just like neutron SGs | 15:03 |
| mspreitz | the k8s net policy is just a set of additive rules | 15:03 |
| apuimedo | mspreitz: good then | 15:03 |
| mspreitz | I talked to another vendor at kubecon that has added more structure, so they can have negatives and overrides | 15:04 |
| mspreitz | but that is not in the k8s net sig policy. | 15:04 |
| mspreitz | Because it is just a set of additive rules, it maps easily to Neutron security groups. | 15:04 |
| apuimedo | salv-orlando: it is almost a matter of necessity, if they want to keep the networking generic and without vendor lock in that the translation into useful enough policy objects is done by the API. Otherwise it is going to be a mess | 15:05 |
| mspreitz | apuimedo: I do not understand what you are saying. The k8s api server just stores the policy objects, not translate them into anything. | 15:05 |
| apuimedo | mspreitz: do you have an example response from the API on the thirdparty creation for people to see. It is generally good to include those kind of things on devref | 15:05 |
| mspreitz | apuimedo: good point, I will add examples. | 15:06 |
| apuimedo | both the definitions in the service description, the response from the API, and example SG creation | 15:06 |
| mspreitz | I do not have examples of translation to SGs, but I think you can find example policy source in the k8s net sig work. | 15:06 |
| *** yamamoto has quit IRC | 15:06 | |
| apuimedo | mspreitz: It would be good to come up with a tentative one for the guestbook example and put it on the devref | 15:07 |
| mspreitz | apuimedo: will do. | 15:07 |
| apuimedo | some people understand better by example than explanation. So it is good to have both | 15:07 |
| banix | mspreitz: yeah | 15:07 |
| mspreitz | agreed, just an oversight in my hurry. | 15:07 |
| vikasc | apuimedo: +1 | 15:07 |
| apuimedo | We're starting to be a bit short on time | 15:07 |
| apuimedo | 8minutes for T2 | 15:07 |
| salv-orlando | apuimedo: as you attend the sig-network meetings quite reguardly you surely know what approach they're adopting. third party resource with completely external processing are a stopgap while we experiment | 15:07 |
| apuimedo | and then we go with irenab | 15:07 |
| salv-orlando | apuimedo: I would not be worried to much about what the API server does or doesn't at this stage | 15:08 |
| mspreitz | actually T2 overlaps with the one of the biggest open issues in irena's proposal, namely multi-tenancy | 15:08 |
| apuimedo | salv-orlando: I know it's a stopgap, but I'm not sure if it will just graduate to the regular API on 1.3 or they are going to leave it for third parties | 15:08 |
| mspreitz | So my proposal for T2 is that each tenant gets its own router, and its Neutron networks attach to its router | 15:09 |
| irenab | I would wait with multi-tenancy for the next phase | 15:09 |
| mspreitz | But since k8s requires all this reachability, we have to augment that with a lot of routes. | 15:09 |
| apuimedo | mspreitz: just so that everyone follows. Here we are talking about ad-hoc multitenancy, or multitenancy from teh OSt point of view. Previous to any multi-tenancy that may eventually be brought on by k8s | 15:10 |
| salv-orlando | apuimedo: third party APIs in k8s are not really APIs... just a way to stash blob of arbitrary json data | 15:10 |
| salv-orlando | so it'll have to graduate to become a thing | 15:10 |
| mspreitz | actually this is an important point, MT in k8s | 15:10 |
| mspreitz | It is not there now, as we all know. | 15:10 |
| apuimedo | salv-orlando: I sure hope it does, but it's not going to be for 1.2, right? | 15:10 |
| salv-orlando | apuimedo: most definetely not | 15:10 |
| mspreitz | I have been supposing that some of us will wedge it in there somehow real soon. | 15:10 |
| mspreitz | (regarding 3rd party resource graduation: yes, it will happen, details TBD, not in 1.2) | 15:11 |
| apuimedo | salv-orlando: that's my point. That until it does, policy and to a bigger extent, multi-tenancy, are scaffolding | 15:11 |
| apuimedo | that are useful for our OSt + k8s operators | 15:11 |
| mspreitz | Some of us are going to do multi-tenancy in k8s real soon, by whatever hook and crook we need to get it creaking along. | 15:12 |
| apuimedo | but that will be in motion and for which we probably can't guarantee bc | 15:12 |
| apuimedo | mspreitz: indeed | 15:12 |
| mspreitz | Right now, I am thinking of a wrapper that adds multi-tenancy and sharding. | 15:12 |
| mspreitz | sharding is beyond the scope of this discussion. | 15:12 |
| apuimedo | mspreitz: sharding not based on namespaces? | 15:12 |
| mspreitz | The important point, I think, is only this: each k8s namespace will belong entirely to exactly one tenant. | 15:12 |
| irenab | tenant can be specified as label on Pod/Namespace | 15:13 |
| mspreitz | So we can put a label on a k8s namespace that identifies the tenant. | 15:13 |
| apuimedo | mspreitz: when you say exactly one tenant is that 1 - 1 or 1 - N | 15:13 |
| banix | sounds reasonable | 15:13 |
| mspreitz | namespace -> tenant is N -> 1 | 15:13 |
| apuimedo | good. I can agree with that | 15:14 |
| mspreitz | And that is why I suppose each k8s has a label identifying the tenant | 15:14 |
| apuimedo | I hope that we all agree that whatever we build for policy and multitenancy will have to be reviewed and possibly changed without BC once the APIs graduate in k8s | 15:14 |
| mspreitz | "BC" ? | 15:15 |
| apuimedo | backwards compatibility | 15:15 |
| banix | British Columbia | 15:15 |
| mspreitz | right | 15:15 |
| mspreitz | the whole point of the current status is that it is not stable | 15:15 |
| salv-orlando | or before christ | 15:15 |
| apuimedo | banix: we were there already ;-) | 15:15 |
| mspreitz | no promise of stability to users | 15:15 |
| salv-orlando | I don't think anyone is even considering backward compatibility | 15:16 |
| mspreitz | that was my position | 15:16 |
| apuimedo | alright. Because our contract with Magnum is that we have to adapt to fit what k8s ends up doing | 15:16 |
| mspreitz | anyway, back to achieving the MT. | 15:16 |
| salv-orlando | the kubernetes folks are rather pragmatic,,,, they won't enforce something like that on a feature they know noone is using | 15:16 |
| apuimedo | good that we all understand that | 15:16 |
| mspreitz | I am not happy with requiring lots of routes | 15:16 |
| mspreitz | I am also not happy that Neutron routers do not exchange routes. Why is that, anyway? | 15:16 |
| apuimedo | mspreitz: you mean like implicit bgp? | 15:17 |
| banix | exchange routes? | 15:17 |
| mspreitz | right | 15:17 |
| irenab | can we please get tot he point of different approaches? We have less than 15 mins | 15:17 |
| apuimedo | heh | 15:17 |
| apuimedo | #topic direct k8s/cni | 15:17 |
| apuimedo | irenab: the floor is yours | 15:17 |
| salv-orlando | irenab is right we've been digressing on several non-essential points | 15:17 |
| irenab | As I see it the main difference with mspreitz approach is on CNI side | 15:18 |
| apuimedo | Native CNI plugin that works similary as the Nova plugging and an API watcher | 15:18 |
| apuimedo | the native API watcher is not that different from mspreitz proposes for networkpolicy monitoring | 15:19 |
| irenab | meaning that neutron API calls are done by watcher and not by CNI | 15:19 |
| apuimedo | and it could take on that job | 15:19 |
| apuimedo | CNM is not involved | 15:19 |
| irenab | CNI gets all required data to complete local binding | 15:19 |
| apuimedo | it gets rid of kube-proxy | 15:19 |
| irenab | apuimedo: hope our notes are synchorized ;-) | 15:20 |
| banix | apuimedo: i thought floor was Irena’s :) | 15:20 |
| apuimedo | banix: it is. I'm just wiping it | 15:20 |
| irenab | banix: we both are deeply involved :-) | 15:20 |
| * apuimedo janitor | 15:20 | |
| banix | :) | 15:20 |
| apuimedo | it allows the usage of FIPs and LBs that are common tools for OSt operators | 15:20 |
| apuimedo | irenab: continue please | 15:20 |
| apuimedo | (the floor is clean now. /me puts slippery floor sign) | 15:21 |
| irenab | I think we have all the details already | 15:21 |
| * mspreitz thinks "we" does not include me | 15:21 | |
| irenab | Watcher gets k8s events and calls neutron | 15:21 |
| apuimedo | mspreitz: this is the place to ask | 15:21 |
| irenab | CNI receives IP, port uuid, mac address via pod annotations and performs local binding | 15:22 |
| apuimedo | personally I prefer not using CNM, but I do like the scaffolding for policy and tenancy that mspreitz is pushing | 15:22 |
| irenab | mspreitz: I meant apuimedo and myself by ‘we’ | 15:22 |
| irenab | apuimedo: for me it is complementary and can be achived by the watcher | 15:23 |
| apuimedo | fawadkhaliq: salv-orlando: vikasc: tfukushima: mspreitz: thoughts? Questions? | 15:23 |
| apuimedo | banix: you too, okay | 15:23 |
| irenab | so the policy agent that mspreitz mentioned is one of the watchers | 15:23 |
| mspreitz | I have some questions. Since we already have a libnetwork plugin that does local binding, why avoid using it? | 15:23 |
| salv-orlando | yeah... can you spend some words on why CNI frees you up to use Floating IPs? | 15:24 |
| salv-orlando | I just don't understand why CNM would not | 15:24 |
| irenab | not sure how CNI/CNM related to FIPs | 15:25 |
| apuimedo | salv-orlando: the API watcher doesn't watch just for Pods (which is what CNI gets info about) | 15:25 |
| apuimedo | it watcher for services | 15:25 |
| apuimedo | which can get externalIP requests defined | 15:25 |
| apuimedo | as well as Loadbalancer type | 15:25 |
| irenab | and replaces kube-proxi | 15:25 |
| salv-orlando | apuimedo: ok... but then if it was the CNI/CNM thing mspreitz did, it could do the same | 15:25 |
| apuimedo | teh API watcher, when it sees those, it does the FIP/lb assignment to the port it creates for CNI | 15:25 |
| salv-orlando | cool guys, you were then referring to the whole solution not the CNI plugin only. | 15:26 |
| mspreitz | Q2: it looks like Irena wants to replace kube-proxy with Neutron load balancers. Can we factor that into a separate spec/devref? It has lots of issues. | 15:26 |
| apuimedo | salv-orlando: exactly | 15:26 |
| irenab | I think there are several not dependent issues we need to discuss | 15:26 |
| irenab | 1. CNI approach | 15:26 |
| irenab | 2. Service implementation | 15:26 |
| irenab | 3. External IP support | 15:26 |
| apuimedo | 3. Policy | 15:27 |
| apuimedo | ui, got my numbering wrong :P | 15:27 |
| apuimedo | 42. tenancy | 15:27 |
| apuimedo | (that padding should give enough space) | 15:27 |
| * salv-orlando apuimedo knows 42 is always ht eirght naswer | 15:27 | |
| apuimedo | :-) | 15:28 |
| banix | I guess avoiding CNM makes sense if we try to consider other container engines. otherwise, why? | 15:28 |
| banix | which is something we should do sooner or later… ok perhaps later | 15:28 |
| irenab | and k8s supports rkt | 15:28 |
| salv-orlando | banix: I think we are digressing too much into this CNI/CNM dicotomy | 15:28 |
| mspreitz | I think avoiding `docker network` makes no sense, it leaves Docker misinformed about connectivity. | 15:28 |
| apuimedo | banix: there is two extra reasons | 15:28 |
| apuimedo | rkt and host access to Neutron APIs | 15:29 |
| salv-orlando | frankly I am ok with supporting both approaches.... and then maybe we can use the pure CNI to provide neutron networking with rkt or whatever | 15:29 |
| irenab | salv-orlando: I wanted to say the same :-) | 15:29 |
| apuimedo | salv-orlando: that's what I proposed from the begining | 15:29 |
| apuimedo | that we'd have a CNI->CNM translation | 15:29 |
| salv-orlando | I would love to focus more on the "watcher" which will give us 2, 4 (apuimedo's 3) and maybe also 3 | 15:29 |
| banix | sounds good | 15:29 |
| apuimedo | now | 15:29 |
| irenab | seems we agree | 15:29 |
| mspreitz | just in time | 15:30 |
| banix | time for group hug | 15:30 |
| apuimedo | then build CNI direct integration for rkt and other advanced stuff we may need to do | 15:30 |
| irenab | banix: :-) | 15:30 |
| apuimedo | one last thing. I'd like a watcher discussion next week | 15:30 |
| apuimedo | #action mspreitz to update the devrefs with examples | 15:30 |
| banix | same time same place apuimedo? | 15:31 |
| salv-orlando | apuimedo: I'm up for it | 15:31 |
| irenab | apuimedo: maybe we can push devref by then | 15:31 |
| apuimedo | banix: yes. THe same bat-hour in the same bat-channel | 15:31 |
| irenab | I won’t be able to attend next week | 15:31 |
| apuimedo | irenab: which? | 15:31 |
| mspreitz | I would rather start 30 min earlier, i possible | 15:31 |
| mspreitz | if possible | 15:31 |
| apuimedo | mspreitz: sounds good to me | 15:31 |
| irenab | apuimedo: for watcher | 15:31 |
| mspreitz | start at 14:00 UTC | 15:31 |
| apuimedo | irenab: yes. THat's a good point | 15:32 |
| apuimedo | let's do that | 15:32 |
| banix | ok with me | 15:32 |
| apuimedo | 14 utc everybody? | 15:32 |
| salv-orlando | lgtm | 15:32 |
| vikasc | ok with me too | 15:32 |
| irenab | apuimedo: thanks a lot for facilitation | 15:32 |
| tfukushima | It's better than 15:00 UTC. | 15:32 |
| apuimedo | very well. Thank you very much to all of you for joining. It was a very nice meeting | 15:32 |
| mspreitz | thank you all | 15:32 |
| apuimedo | #endmeeting | 15:32 |
| openstack | Meeting ended Wed Mar 16 15:32:45 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:32 |
| banix | thank you | 15:32 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/k8s_integration_discussion/2016/k8s_integration_discussion.2016-03-16-14.30.html | 15:32 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/k8s_integration_discussion/2016/k8s_integration_discussion.2016-03-16-14.30.txt | 15:32 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/k8s_integration_discussion/2016/k8s_integration_discussion.2016-03-16-14.30.log.html | 15:32 |
| salv-orlando | adieuuuu | 15:32 |
| fawadkhaliq | bye | 15:33 |
| *** fawadkhaliq has quit IRC | 15:33 | |
| irenab | bye | 15:33 |
| apuimedo | Adéu | 15:33 |
| *** apuimedo has quit IRC | 15:33 | |
| *** fawadkhaliq has joined #openstack-kuryr | 15:34 | |
| *** tfukushima has quit IRC | 15:38 | |
| *** fawadkhaliq has quit IRC | 15:38 | |
| mspreitz | BTW, where do I find this guestbook example that was mentioned? | 15:56 |
| mspreitz | I suppose https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook is it. | 15:58 |
| *** vikasc has quit IRC | 16:00 | |
| *** fawadkhaliq has joined #openstack-kuryr | 16:04 | |
| *** yamamoto has joined #openstack-kuryr | 16:07 | |
| *** yamamoto has quit IRC | 16:16 | |
| *** fawadkhaliq has quit IRC | 16:32 | |
| *** fawadkhaliq has joined #openstack-kuryr | 16:33 | |
| *** fawadkhaliq has quit IRC | 16:33 | |
| *** fawadkhaliq has joined #openstack-kuryr | 16:50 | |
| *** fawadkhaliq has quit IRC | 16:51 | |
| *** fawadkhaliq has joined #openstack-kuryr | 16:51 | |
| *** banix has quit IRC | 17:01 | |
| *** banix has joined #openstack-kuryr | 17:02 | |
| *** mspreitz has quit IRC | 17:17 | |
| *** fawadkhaliq has quit IRC | 17:49 | |
| *** fawadkhaliq has joined #openstack-kuryr | 17:50 | |
| *** salv-orl_ has joined #openstack-kuryr | 17:54 | |
| *** salv-orlando has quit IRC | 17:56 | |
| fkautz | devstack is so slow :( | 18:25 |
| fkautz | anyone have any recommendations on speeding it up? | 18:26 |
| fawadkhaliq | fkautz: because of kuryr? :O | 18:41 |
| fawadkhaliq | or Internet speed? :-) | 18:42 |
| fkautz | fawadkhaliq: i think it's devstack just being ridiculously slow | 18:42 |
| fkautz | internet speed isn't a problem :p | 18:42 |
| fkautz | although, git has been taking a long time, i did manage to get some speedup with GIT_BASE=https://github.com | 18:42 |
| fawadkhaliq | fkautz: hehe okay :) | 18:43 |
| fkautz | git clone is blazing, devstack's git clone is incredibly slow | 18:43 |
| fkautz | especially nova :p | 18:43 |
| fkautz | cloning nova has timed out on me a few times... 600s timeout | 18:43 |
| fawadkhaliq | fkautz: ah, seems like github issue | 18:43 |
| fkautz | timeouts were before setting git base | 18:44 |
| fkautz | but it's still slow :p just not slow enough to time out | 18:44 |
| *** fawadkhaliq has quit IRC | 18:49 | |
| *** salv-orl_ has quit IRC | 19:15 | |
| *** irenab_ has joined #openstack-kuryr | 19:26 | |
| *** irenab has quit IRC | 19:28 | |
| *** irenab_ is now known as irenab | 19:28 | |
| *** salv-orlando has joined #openstack-kuryr | 20:01 | |
| *** diogogmt has joined #openstack-kuryr | 20:33 | |
| *** banix has quit IRC | 20:45 | |
| *** fawadkhaliq has joined #openstack-kuryr | 23:19 | |
| fkautz | fawadkhaliq: enabling virtio in vbox sped it up considerably | 23:36 |
| fkautz | opened a bug in vagrant asking them to use virtio by default if available :) | 23:37 |
| *** diogogmt has quit IRC | 23:38 | |
| fawadkhaliq | fkautz: ah, your vnics | 23:41 |
| *** salv-orl_ has joined #openstack-kuryr | 23:54 | |
| *** salv-orlando has quit IRC | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!