Wednesday, 2016-02-03

*** banix has joined #openstack-kuryr00:37
*** banix has quit IRC00:43
*** shashank_hegde has quit IRC01:32
*** baohua has joined #openstack-kuryr02:05
*** banix has joined #openstack-kuryr02:06
*** salv-orl_ has joined #openstack-kuryr02:09
*** salv-orlando has quit IRC02:12
*** banix has quit IRC03:17
*** yuanying_ has quit IRC03:20
*** yuanying has joined #openstack-kuryr03:24
*** shashank_hegde has joined #openstack-kuryr03:42
*** tfukushima has joined #openstack-kuryr03:54
*** yuanying has quit IRC04:06
*** yuanying has joined #openstack-kuryr04:07
*** irenab_ has joined #openstack-kuryr04:09
*** irenab has quit IRC04:11
*** irenab_ is now known as irenab04:11
*** tfukushima has quit IRC04:18
*** tfukushima has joined #openstack-kuryr05:02
*** diga has joined #openstack-kuryr05:19
*** diga has quit IRC06:19
*** diga has joined #openstack-kuryr07:09
*** wanghua has joined #openstack-kuryr07:45
*** salv-orlando has joined #openstack-kuryr08:10
*** salv-orl_ has quit IRC08:12
*** salv-orlando has quit IRC08:14
*** salv-orlando has joined #openstack-kuryr08:14
*** shashank_hegde has quit IRC08:25
*** apuimedo|away has joined #openstack-kuryr08:39
*** salv-orlando has quit IRC08:52
*** apuimedo|away has quit IRC09:02
*** apuimedo|away has joined #openstack-kuryr09:04
*** tfukushima has quit IRC09:51
*** tfukushima has joined #openstack-kuryr09:51
*** devvesa has joined #openstack-kuryr09:51
*** devvesa has quit IRC10:04
*** tfukushima has quit IRC10:09
*** salv-orlando has joined #openstack-kuryr10:16
*** salv-orlando has quit IRC10:21
*** apuimedo|away is now known as apuimedo10:55
*** salv-orlando has joined #openstack-kuryr11:07
*** diga has quit IRC11:26
*** apuimedo is now known as apuimedo|lunch11:56
*** banix has joined #openstack-kuryr12:07
*** baohua has quit IRC12:34
*** banix has quit IRC12:48
*** openstackgerrit has quit IRC13:02
*** openstackgerrit has joined #openstack-kuryr13:02
*** baohua has joined #openstack-kuryr13:48
*** apuimedo|lunch is now known as apuimedo13:57
*** apuimedo has quit IRC14:13
*** apuimedo has joined #openstack-kuryr14:13
*** banix has joined #openstack-kuryr14:22
*** mdunn has joined #openstack-kuryr14:25
*** banix has quit IRC14:26
*** apuimedo has quit IRC14:34
*** mdunn has quit IRC14:34
*** mark_dunn has joined #openstack-kuryr14:44
*** baohua has quit IRC14:50
*** apuimedo has joined #openstack-kuryr14:57
*** gsagie_ has joined #openstack-kuryr15:16
*** banix has joined #openstack-kuryr15:18
apuimedoHello folks15:31
apuimedo#startmeeting k8s integration15:31
openstackMeeting started Wed Feb  3 15:31:53 2016 UTC and is due to finish in 60 minutes.  The chair is apuimedo. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:31
openstackThe meeting name has been set to 'k8s_integration'15:31
apuimedowho's here for the meeting?15:32
apuimedoirena said she'd be late15:33
apuimedofkautz: you there?15:33
gsagie_irena!!!! :)15:34
apuimedoirenab: is not that late :P15:34
irenabalmost on time :-)15:34
irenabgsagie: also glad to see you :-) !15:34
apuimedowell, I was hoping there would be more people, but we have a nice cozy assemble15:35
apuimedoalright, let's start15:35
banixsalv-orlando: you here by any chance?15:36
irenabshall we start from use cases?15:36
apuimedoI forgot where we left off15:36
apuimedoah yes15:36
banixwe wrer in a forrest and looking for a way out?15:37
apuimedooption T vs option T+F vs option F15:37
apuimedobanix: look left15:37
banixalways the right direction15:37
irenablets focus on what we will support and then how?15:37
banixT was?15:37
gsagie_translation to libnetwork15:38
banixand F?15:38
gsagie_and the other just to implement the CNI15:38
gsagie_two different solutions15:38
gsagie_integrate with Kubernetes15:38
irenabI thought we already decided to drop T15:39
gsagie_its good with me15:39
apuimedoirenab: no, we did not15:39
gsagie_the only reason was that someone (i think Matt)15:39
gsagie_wanted to try and work on it in parallel15:39
gsagie_Mike yeah15:39
apuimedoMike Spreitzer15:39
apuimedothough I think there's a big consensus in reducing it to option t+f vs option F15:40
apuimedoI vote to reduce it to that15:40
apuimedodo you all agree?15:40
banixapuimedo: what is exactly T+F?15:41
irenabI already thought we agreed on this :-)15:41
banixseems you all left me in the forrest :)15:41
gsagie_banix: work on them in parallel together, i guess apuimedo things that translation to lib network is something we can do pretty quick15:41
gsagie_for fast term goal15:41
irenabbanix: looks I am in the forest too, maybe the different one15:41
banixso long term solution we think is F. Right?15:41
banixirenab: :)15:42
gsagie_i only remember it from our last meeting, and i wasn't concentrating most of the time :)15:42
gsagie_i think since Mike is not here, we don't focus on this because there is no one that is actually going to devote time to do it, apuimedo: do you have anyone for this?15:42
apuimedobanix: yes15:42
gsagie_atlas not focus in this meeting15:42
banixjust confused about reducing to T+F which is more like expanding to T+F15:43
apuimedogsagie_: well, I haven't dropped completely doing some sort of T15:43
apuimedowhile we work on F15:43
apuimedofor me it would be, have somebody working on the CNI driver15:43
apuimedosomebody working on the etcd component that sends commands to Neutron15:44
irenabapuimedo: Can we please focus on WHAT before HOW?15:44
apuimedoand, while we refactor, we can translate to libnetwork15:44
apuimedoirenab: you got me15:44
irenabI think its easier to move with how :-)15:44
apuimedo#topic HOW15:45
apuimedomy proposal is that we do two components15:46
banixi think ireana meant after we are done with WHAT15:46
apuimedooh right15:46
irenabbanix: I do beleive we are in the same forrest :-)15:46
apuimedo#topic WHAT!!!15:46
apuimedoI'm sorry for the confusion15:47
irenabShall we first support the “flat”, i.e. current k8s networking mode or we want to go forward with Network Policy proposal?15:47
apuimedoF should start directly with the policy proposal15:47
irenabdo we want to have annotation/label based expressions supported?15:47
irenabI think its probably matter of what k8s version we want to support15:48
irenabthe proposal will probably land in 1.215:48
apuimedo1.2 is the target I think15:49
gsagie_we want something that query etcd and translate to Kuryr15:49
irenabgsagie: yes on what part?15:49
gsagie_yes we want to have annotation/label based expressions supported, which means we define special labels/annotations for certain configuration in Neutron right?15:49
irenabsounds good to me15:50
apuimedogsagie_: I think extra label support is a plus, but not an immediate requisite15:50
apuimedobut yeah... I'd like to have it to be able to specify lb settings and other stuff15:50
gsagie_ok, so what features currently in Kubernetes we want to support? we want the basic stuff of creating the networks right?15:50
gsagie_and the lb replacing kube-proxy15:50
apuimedogsagie_: yes, that's the minimum15:51
apuimedoLB for replication15:51
gsagie_for services15:51
irenabif we want to support Policy, it may require SG15:51
apuimedoFIP for load balancer mode15:51
irenabso its connectivity + ACL15:51
gsagie_okie, so the CNI already gives us the first part, for the services configuration we need to listen to etcd?15:51
irenabseems we may need the listener to support both services and policies15:52
gsagie_which is services VIPs and north-south LB15:52
banixyes we need SG but that would be ok15:52
apuimedogsagie_: but CNI, as it is used in k8s now, IIRC only tells you to join the network that exists in the worker node15:52
apuimedowe need it to be able to get network per tier for example15:53
irenabapuimedo: I think this is something that needs to be concluded from the models15:53
gsagie_apuimedo: okie, so it seems to me that the challenge here will be to sync between the information we read from etcd and the CNI which needs to do the binding part15:54
apuimedoso another "What" we need is15:54
apuimedogsagie_: exactly, you erad my mind15:54
*** salv-orl_ has joined #openstack-kuryr15:54
apuimedo* find a way for having the entities created by the watcher in the cni driver15:54
apuimedoso that they can be used15:54
irenabso we may even think of once understanding the model and doing some operations for neutron, add annotations after the actions to be processed by CNI15:55
apuimedoI believe they have a similar issue in k8s-net-sig15:55
apuimedothey were considering pushing the data down all the way to the cni15:55
apuimedobut I'm not sure if it's going to happen nor if it is the right thing15:55
gsagie_we can always read the etcd DB from our CNI implementation15:55
irenabapuimedo: initially we may add details via annotations in scope of the watcher15:55
gsagie_the problem is what happens first15:55
apuimedogsagie_: I'm not sure how operators would feel about that, but it is a good option15:56
irenabgsagie: I hope we can avoid this15:56
*** salv-orlando has quit IRC15:57
apuimedoirenab: me too15:57
irenabCNI plugin should be not k8s specifc, at least ecventualy15:57
apuimedoI'd want the cni driver to be able to do with as little as possible15:57
apuimedoso that ideally15:57
apuimedoit would only learn about the ip in the worst case15:57
*** leecalcote has joined #openstack-kuryr15:58
apuimedoor uuid/vlan(for nested) in the best base15:58
irenabapuimedo:  there is both network and IPAM drivers15:58
apuimedoI would like to do the ipam in the watcher15:58
apuimedoto speed up15:58
gsagie_one option is that we keep the CNI operations in Kuryr in a queue and wait until the watcher added the correct port in neutron and only then do the binding15:58
apuimedoI would be overjoyed if the worker nodes don't need to have access to the neutron api15:58
apuimedoand they can make do with the mq15:59
irenabmq for what?15:59
banixgsagie_: why? for applying acl?15:59
gsagie_banix: we have a watcher that listen to etcd, it gets all the relevant information (IPAM/SG/correct network) from etcd and then call the Neutron API from the master16:00
gsagie_then the CNI driver only do the binding part16:00
apuimedoirenab: mq for the ovs neutron agent16:00
gsagie_connect the neutron port to the container namespace16:00
irenabapuimedo: this is backend dependent16:00
apuimedoirenab: the point is16:01
apuimedoIf possible, the worker nodes shouldn't need to be on the neutron management network16:01
gsagie_so we basically have something that integrate with Kubernetes "API" by listening to the etcd DB (can later use labels and annotations) and configure Neutron, then the end points in the nodes only do the binding16:02
irenabapuimedo:  at least not talk to neutron API16:02
apuimedowe have it in plain kuryr libnetwork because there is no orchestration we can check (well, with cluster store we could correct it, but that is another topic)16:02
gsagie_apuimedo, irenab: what do you think about that?16:02
apuimedogsagie_: that's the goal, yes16:02
irenabgsagie_: I agree16:02
gsagie_apuimedo: okie, so i think we have defined it16:03
apuimedogsagie_: thanks for synthesizing it16:03
irenabso we are ok with How while discussing what :-)16:03
gsagie_i think we also agree on the what16:03
apuimedothe rest of the what is16:03
gsagie_just how to model to Neutron16:03
apuimedogsagie_: take a stab at synthesizing it16:03
apuimedoyou are on a roll16:03
gsagie_i think we need to do the simplest thing at first stage just to build the "infrastructure" for the different components16:04
irenabyes, and probably to define the lables/annotation we may expect as part of the k8s model entities16:04
*** leecalcote has quit IRC16:04
gsagie_so i guess you want to model it-> service=network16:04
irenabwhat about namespaces isolation option?16:05
apuimedogsagie_: yes, that's the simplest and more common use case we can support16:05
gsagie_and then add routing between them, at first between all16:05
irenabwe may consider pods (RC) to be on the same network regardless the service16:05
apuimedoirenab: I'm tempted to say that namespaces is something that I want to ignore for the time being16:06
irenabI think in some simple examples there are only Pods16:06
apuimedoin the sense that we would not isolate namespaces of the same tenant16:06
apuimedobut I'm not 80% on this16:06
irenabapuimedo: do we have multi-tenancy?16:06
apuimedoso I can be easily convinced16:06
apuimedoirenab: sort of xD16:06
banixwell tenants don’t go across namespaces. no?16:07
apuimedobut now it relies on one host per tenant16:07
gsagie_multi tenancy is just how you connect the relevant networks to a router16:07
gsagie_i think16:07
banixnottalking about network namespaces16:07
apuimedobanix: no. exactly. But tenants could have several namespaces16:07
*** leecalcote has joined #openstack-kuryr16:07
irenabk8s namespaces16:07
banixwll are you talking about k8s namespace16:07
apuimedoI am talking to k8s namespaces, yes16:08
apuimedoirenab: I think that for multitenancy we will have to rely on the multitenancy that they are adding to k8s16:09
irenabso back to What, I think we should define scenarious to support, i.e. assuming all k8s namespace are not isolated16:09
apuimedoand somehow bundle authorization there16:09
irenabapuimedo: do you have any details on what is the k8s plan for multi-tenancy?16:09
apuimedoso that in etcd we can get the auth of the tenant that is associated to the service16:09
apuimedoand try to perform the neutron action with their auth16:10
apuimedoirenab: not in hand, no16:10
irenabapuimedo: this can be great, but we will need to manage tenants in keystone?16:10
apuimedoirenab: I was thinking something simpler16:10
apuimedothat somehow the creds would end up in etcd16:10
irenabassuming no multi-tenancy should be ok for now, agreee?16:10
apuimedoyes. without mulit-tenancy we should be ok16:11
irenabgsagie_: banix ?16:12
apuimedohey, does any of you remember if it was possible to create an arbitrary token for a user in keystone?16:12
banixapuimedo: what do you mean by arbitrary?16:12
gsagie_i am fine with it, i don't see the challenge if etcd support the namespace, we only need the "watcher" thread to have the various different tenants16:12
gsagie_unless i didnt get something16:12
gsagie_but i am not too familiar with the k8 namespaces yet16:13
gsagie_but we can work without them at first16:13
irenabI think we need to see how to reflect this in neutron16:13
apuimedoI meant like oath token like k8s uses16:13
gsagie_irenab: why this can't be different OS tenants?16:13
gsagie_different Neutron tenants16:13
banixa tenant can create tokens at will but i am probably missing your point16:13
irenabgsagie_: who defines them and when?16:13
apuimedohey guys16:14
apuimedoand gals16:14
apuimedok8s supports keystone auth16:14
irenablets handle multi-tenancy for next phase16:14
apuimedowe may just require it16:14
irenabapuimedo: cool16:14
apuimedoI'm not sure how big a handicap it will be for operators to accept keystone16:15
apuimedobut I'm sure big operators should be content with it16:15
apuimedoI'm betting openshift uses it16:15
apuimedoso we could say16:15
apuimedoif k8s keystone integration is configured it is multitenant, otherwise it is single tenant16:15
apuimedofor starters16:15
irenabapuimedo: I think we need to verify the k8s approach for app multi-tenancy16:16
gsagie_sorry need to go all :) but i think the first start of the work is defined, so we can start coding and defining in parallel the next bits16:16
irenabapuimedo: this maybe related to the whole cluster16:16
gsagie_if it integrates with keystone that would be great16:16
apuimedo#info we basically have something that integrate with Kubernetes "API" by listening to the etcd DB (can later use labels and annotations) and configure Neutron, then the end points in the nodes only do the binding16:17
gsagie_yes challenge, we need to be able to keep the binding until neutron configuration has ended16:17
apuimedogsagie_: banix: irenab: what about we create a blueprint with what we discussed16:18
apuimedoand as soon as it matures a bit we put it on a spec16:18
apuimedocompletely WIP16:18
banixsounds good16:18
irenabgsagie_: we need to check contrail approach, I think they have similar components16:18
apuimedoor we can go straight for wip spec if you see fit16:18
irenabapuimedo: I will try to arrange initial draft version16:18
apuimedoas it seems people comment more on spec16:19
apuimedoirena: you just earned an extra cheese delivery16:19
irenabapuimedo: :-)16:19
apuimedo#topic other16:19
irenabthe last one was very good16:19
apuimedothat was extra :-)16:19
apuimedoanything else?16:19
gsagie_somebody look at what contrail are doing16:20
gsagie_i am fine doing it16:20
apuimedoI'm delivering catalan cheese straight from the farm :-)16:20
apuimedogsagie_: if you can take a look at the etcd watcher, that'd be great16:20
irenabgsagie_:banix you better go for the cheese than T-bone16:20
apuimedoalright, so let's close up16:21
apuimedo#action irena to submit WIP spec16:21
apuimedo#action gsagie to look at contrail watcher16:21
openstackMeeting ended Wed Feb  3 16:22:02 2016 UTC.  Information about MeetBot at . (v 0.1.4)16:22
openstackMinutes (text):
apuimedoThanks a lot for joining folks!16:22
gsagie_thanks all, thanks apuimedo for the great topics ;)16:22
irenabapuimedo:  I meant blueprint :-)16:22
apuimedoirenab: too late, now it's in the minutes :D16:22
irenabapuimedo: you will need to provide extra extra cheese delivery16:22
apuimedo( •_•)>⌐■-■,16:22
apuimedowe'll see what can be done16:23
irenabthanks guys, bye16:23
apuimedothey'll arrest you for smuggling16:23
*** shashank_hegde has joined #openstack-kuryr16:23
*** banix has quit IRC16:24
*** leecalcote has quit IRC16:30
*** gsagie_ has quit IRC16:33
*** mark_dunn has quit IRC17:08
apuimedogsagie: fkautz tells me that etcd watching is being closed down. Please, check the k8s watching apis17:08
apuimedoto see if they offer enough data for our net purposes or we need to contribute there17:09
salv-orl_apuimedo, gsagie, banix: sorry for missing the discussion guys. I had unfortunately another meeting going on. I will catch up on the logs.17:10
apuimedosalv-orl_: very well, ask if you need any clarification17:10
salv-orl_apuimedo: will do thanks17:11
*** devvesa has joined #openstack-kuryr17:42
*** shashank_hegde has quit IRC17:50
*** banix has joined #openstack-kuryr18:07
*** devvesa has quit IRC18:12
*** shashank_hegde has joined #openstack-kuryr18:14
*** apuimedo has quit IRC18:57
banixgsagie: irenab mestery apuimedo Added Kuryr as a docker plugin to the docker docs here:
mesterybanix: You rock my friend :)20:32
*** salv-orlando has joined #openstack-kuryr21:54
*** salv-orl_ has quit IRC21:56
*** banix has quit IRC22:26
*** yuanying has quit IRC23:54
*** yuanying has joined #openstack-kuryr23:56

Generated by 2.14.0 by Marius Gedminas - find it at!