| *** banix has joined #openstack-kuryr | 00:37 | |
| *** banix has quit IRC | 00:43 | |
| *** shashank_hegde has quit IRC | 01:32 | |
| *** baohua has joined #openstack-kuryr | 02:05 | |
| *** banix has joined #openstack-kuryr | 02:06 | |
| *** salv-orl_ has joined #openstack-kuryr | 02:09 | |
| *** salv-orlando has quit IRC | 02:12 | |
| *** banix has quit IRC | 03:17 | |
| *** yuanying_ has quit IRC | 03:20 | |
| *** yuanying has joined #openstack-kuryr | 03:24 | |
| *** shashank_hegde has joined #openstack-kuryr | 03:42 | |
| *** tfukushima has joined #openstack-kuryr | 03:54 | |
| *** yuanying has quit IRC | 04:06 | |
| *** yuanying has joined #openstack-kuryr | 04:07 | |
| *** irenab_ has joined #openstack-kuryr | 04:09 | |
| *** irenab has quit IRC | 04:11 | |
| *** irenab_ is now known as irenab | 04:11 | |
| *** tfukushima has quit IRC | 04:18 | |
| *** tfukushima has joined #openstack-kuryr | 05:02 | |
| *** diga has joined #openstack-kuryr | 05:19 | |
| *** diga has quit IRC | 06:19 | |
| *** diga has joined #openstack-kuryr | 07:09 | |
| *** wanghua has joined #openstack-kuryr | 07:45 | |
| *** salv-orlando has joined #openstack-kuryr | 08:10 | |
| *** salv-orl_ has quit IRC | 08:12 | |
| *** salv-orlando has quit IRC | 08:14 | |
| *** salv-orlando has joined #openstack-kuryr | 08:14 | |
| *** shashank_hegde has quit IRC | 08:25 | |
| *** apuimedo|away has joined #openstack-kuryr | 08:39 | |
| *** salv-orlando has quit IRC | 08:52 | |
| *** apuimedo|away has quit IRC | 09:02 | |
| *** apuimedo|away has joined #openstack-kuryr | 09:04 | |
| *** tfukushima has quit IRC | 09:51 | |
| *** tfukushima has joined #openstack-kuryr | 09:51 | |
| *** devvesa has joined #openstack-kuryr | 09:51 | |
| *** devvesa has quit IRC | 10:04 | |
| *** tfukushima has quit IRC | 10:09 | |
| *** salv-orlando has joined #openstack-kuryr | 10:16 | |
| *** salv-orlando has quit IRC | 10:21 | |
| *** apuimedo|away is now known as apuimedo | 10:55 | |
| *** salv-orlando has joined #openstack-kuryr | 11:07 | |
| *** diga has quit IRC | 11:26 | |
| *** apuimedo is now known as apuimedo|lunch | 11:56 | |
| *** banix has joined #openstack-kuryr | 12:07 | |
| *** baohua has quit IRC | 12:34 | |
| *** banix has quit IRC | 12:48 | |
| *** openstackgerrit has quit IRC | 13:02 | |
| *** openstackgerrit has joined #openstack-kuryr | 13:02 | |
| *** baohua has joined #openstack-kuryr | 13:48 | |
| *** apuimedo|lunch is now known as apuimedo | 13:57 | |
| *** apuimedo has quit IRC | 14:13 | |
| *** apuimedo has joined #openstack-kuryr | 14:13 | |
| *** banix has joined #openstack-kuryr | 14:22 | |
| *** mdunn has joined #openstack-kuryr | 14:25 | |
| *** banix has quit IRC | 14:26 | |
| *** apuimedo has quit IRC | 14:34 | |
| *** mdunn has quit IRC | 14:34 | |
| *** mark_dunn has joined #openstack-kuryr | 14:44 | |
| *** baohua has quit IRC | 14:50 | |
| *** apuimedo has joined #openstack-kuryr | 14:57 | |
| *** gsagie_ has joined #openstack-kuryr | 15:16 | |
| *** banix has joined #openstack-kuryr | 15:18 | |
| apuimedo | Hello folks | 15:31 |
|---|---|---|
| apuimedo | #startmeeting k8s integration | 15:31 |
| openstack | Meeting 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 http://wiki.debian.org/MeetBot. | 15:31 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:31 |
| openstack | The meeting name has been set to 'k8s_integration' | 15:31 |
| apuimedo | who's here for the meeting? | 15:32 |
| banix | o/ | 15:32 |
| gsagie_ | hi | 15:32 |
| apuimedo | irena said she'd be late | 15:33 |
| apuimedo | fkautz: you there? | 15:33 |
| irenab | hi | 15:34 |
| gsagie_ | irena!!!! :) | 15:34 |
| apuimedo | irenab: is not that late :P | 15:34 |
| irenab | almost on time :-) | 15:34 |
| irenab | gsagie: also glad to see you :-) ! | 15:34 |
| apuimedo | well, I was hoping there would be more people, but we have a nice cozy assemble | 15:35 |
| apuimedo | *assembly | 15:35 |
| apuimedo | alright, let's start | 15:35 |
| banix | salv-orlando: you here by any chance? | 15:36 |
| irenab | shall we start from use cases? | 15:36 |
| apuimedo | mmm | 15:36 |
| apuimedo | I forgot where we left off | 15:36 |
| apuimedo | ah yes | 15:36 |
| banix | we wrer in a forrest and looking for a way out? | 15:37 |
| apuimedo | option T vs option T+F vs option F | 15:37 |
| apuimedo | banix: look left | 15:37 |
| banix | always the right direction | 15:37 |
| irenab | lets focus on what we will support and then how? | 15:37 |
| banix | T was? | 15:37 |
| gsagie_ | translation to libnetwork | 15:38 |
| banix | and F? | 15:38 |
| gsagie_ | and the other just to implement the CNI | 15:38 |
| gsagie_ | two different solutions | 15:38 |
| banix | thx | 15:38 |
| gsagie_ | integrate with Kubernetes | 15:38 |
| irenab | I thought we already decided to drop T | 15:39 |
| gsagie_ | its good with me | 15:39 |
| apuimedo | irenab: no, we did not | 15:39 |
| gsagie_ | the only reason was that someone (i think Matt) | 15:39 |
| gsagie_ | wanted to try and work on it in parallel | 15:39 |
| apuimedo | Mike | 15:39 |
| gsagie_ | Mike yeah | 15:39 |
| apuimedo | Mike Spreitzer | 15:39 |
| apuimedo | though I think there's a big consensus in reducing it to option t+f vs option F | 15:40 |
| apuimedo | I vote to reduce it to that | 15:40 |
| apuimedo | do you all agree? | 15:40 |
| banix | apuimedo: what is exactly T+F? | 15:41 |
| gsagie_ | ok | 15:41 |
| irenab | I already thought we agreed on this :-) | 15:41 |
| banix | seems 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 quick | 15:41 |
| gsagie_ | for fast term goal | 15:41 |
| gsagie_ | thinks | 15:41 |
| banix | ok | 15:41 |
| irenab | banix: looks I am in the forest too, maybe the different one | 15:41 |
| banix | so long term solution we think is F. Right? | 15:41 |
| banix | irenab: :) | 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 |
| apuimedo | banix: yes | 15:42 |
| gsagie_ | atlas not focus in this meeting | 15:42 |
| gsagie_ | atleast | 15:43 |
| banix | just confused about reducing to T+F which is more like expanding to T+F | 15:43 |
| apuimedo | gsagie_: well, I haven't dropped completely doing some sort of T | 15:43 |
| apuimedo | while we work on F | 15:43 |
| apuimedo | for me it would be, have somebody working on the CNI driver | 15:43 |
| apuimedo | somebody working on the etcd component that sends commands to Neutron | 15:44 |
| irenab | apuimedo: Can we please focus on WHAT before HOW? | 15:44 |
| apuimedo | and, while we refactor, we can translate to libnetwork | 15:44 |
| apuimedo | irenab: you got me | 15:44 |
| apuimedo | :-D | 15:44 |
| irenab | I think its easier to move with how :-) | 15:44 |
| apuimedo | ok | 15:45 |
| apuimedo | #topic HOW | 15:45 |
| apuimedo | alright | 15:45 |
| apuimedo | my proposal is that we do two components | 15:46 |
| banix | i think ireana meant after we are done with WHAT | 15:46 |
| apuimedo | oh right | 15:46 |
| irenab | banix: I do beleive we are in the same forrest :-) | 15:46 |
| apuimedo | #topic WHAT!!! | 15:46 |
| apuimedo | I'm sorry for the confusion | 15:47 |
| irenab | Shall we first support the “flat”, i.e. current k8s networking mode or we want to go forward with Network Policy proposal? | 15:47 |
| apuimedo | F should start directly with the policy proposal | 15:47 |
| irenab | do we want to have annotation/label based expressions supported? | 15:47 |
| irenab | I think its probably matter of what k8s version we want to support | 15:48 |
| irenab | the proposal will probably land in 1.2 | 15:48 |
| gsagie_ | yes | 15:48 |
| apuimedo | 1.2 is the target I think | 15:49 |
| gsagie_ | we want something that query etcd and translate to Kuryr | 15:49 |
| irenab | gsagie: 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 |
| irenab | sounds good to me | 15:50 |
| apuimedo | gsagie_: I think extra label support is a plus, but not an immediate requisite | 15:50 |
| apuimedo | but yeah... I'd like to have it to be able to specify lb settings and other stuff | 15: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-proxy | 15:50 |
| apuimedo | gsagie_: yes, that's the minimum | 15:51 |
| banix | +1 | 15:51 |
| apuimedo | LB for replication | 15:51 |
| gsagie_ | for services | 15:51 |
| irenab | if we want to support Policy, it may require SG | 15:51 |
| apuimedo | FIP for load balancer mode | 15:51 |
| irenab | so its connectivity + ACL | 15:51 |
| gsagie_ | okie, so the CNI already gives us the first part, for the services configuration we need to listen to etcd? | 15:51 |
| irenab | seems we may need the listener to support both services and policies | 15:52 |
| gsagie_ | which is services VIPs and north-south LB | 15:52 |
| banix | yes we need SG but that would be ok | 15:52 |
| apuimedo | gsagie_: but CNI, as it is used in k8s now, IIRC only tells you to join the network that exists in the worker node | 15:52 |
| apuimedo | we need it to be able to get network per tier for example | 15:53 |
| irenab | apuimedo: I think this is something that needs to be concluded from the models | 15:53 |
| apuimedo | exactly | 15:54 |
| 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 part | 15:54 |
| apuimedo | so another "What" we need is | 15:54 |
| apuimedo | gsagie_: exactly, you erad my mind | 15:54 |
| apuimedo | *read | 15:54 |
| *** salv-orl_ has joined #openstack-kuryr | 15:54 | |
| apuimedo | * find a way for having the entities created by the watcher in the cni driver | 15:54 |
| apuimedo | so that they can be used | 15:54 |
| irenab | so we may even think of once understanding the model and doing some operations for neutron, add annotations after the actions to be processed by CNI | 15:55 |
| apuimedo | I believe they have a similar issue in k8s-net-sig | 15:55 |
| apuimedo | they were considering pushing the data down all the way to the cni | 15:55 |
| apuimedo | but I'm not sure if it's going to happen nor if it is the right thing | 15:55 |
| gsagie_ | we can always read the etcd DB from our CNI implementation | 15:55 |
| irenab | apuimedo: initially we may add details via annotations in scope of the watcher | 15:55 |
| gsagie_ | the problem is what happens first | 15:55 |
| apuimedo | gsagie_: I'm not sure how operators would feel about that, but it is a good option | 15:56 |
| irenab | gsagie: I hope we can avoid this | 15:56 |
| *** salv-orlando has quit IRC | 15:57 | |
| apuimedo | irenab: me too | 15:57 |
| irenab | CNI plugin should be not k8s specifc, at least ecventualy | 15:57 |
| apuimedo | I'd want the cni driver to be able to do with as little as possible | 15:57 |
| apuimedo | so that ideally | 15:57 |
| apuimedo | it would only learn about the ip in the worst case | 15:57 |
| *** leecalcote has joined #openstack-kuryr | 15:58 | |
| apuimedo | or uuid/vlan(for nested) in the best base | 15:58 |
| apuimedo | *case | 15:58 |
| irenab | apuimedo: there is both network and IPAM drivers | 15:58 |
| apuimedo | I would like to do the ipam in the watcher | 15:58 |
| apuimedo | to speed up | 15: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 binding | 15:58 |
| apuimedo | I would be overjoyed if the worker nodes don't need to have access to the neutron api | 15:58 |
| apuimedo | and they can make do with the mq | 15:59 |
| irenab | mq for what? | 15:59 |
| banix | gsagie_: 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 master | 16:00 |
| gsagie_ | then the CNI driver only do the binding part | 16:00 |
| apuimedo | irenab: mq for the ovs neutron agent | 16:00 |
| gsagie_ | connect the neutron port to the container namespace | 16:00 |
| irenab | apuimedo: this is backend dependent | 16:00 |
| apuimedo | irenab: the point is | 16:01 |
| apuimedo | If possible, the worker nodes shouldn't need to be on the neutron management network | 16: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 binding | 16:02 |
| irenab | apuimedo: at least not talk to neutron API | 16:02 |
| apuimedo | we 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 |
| apuimedo | gsagie_: that's the goal, yes | 16:02 |
| irenab | gsagie_: I agree | 16:02 |
| gsagie_ | apuimedo: okie, so i think we have defined it | 16:03 |
| gsagie_ | irenab | 16:03 |
| apuimedo | gsagie_: thanks for synthesizing it | 16:03 |
| irenab | so we are ok with How while discussing what :-) | 16:03 |
| gsagie_ | i think we also agree on the what | 16:03 |
| apuimedo | the rest of the what is | 16:03 |
| gsagie_ | just how to model to Neutron | 16:03 |
| gsagie_ | networks/routers | 16:03 |
| apuimedo | gsagie_: take a stab at synthesizing it | 16:03 |
| apuimedo | :P | 16:03 |
| apuimedo | you are on a roll | 16:03 |
| gsagie_ | heh | 16:04 |
| gsagie_ | i think we need to do the simplest thing at first stage just to build the "infrastructure" for the different components | 16:04 |
| irenab | yes, and probably to define the lables/annotation we may expect as part of the k8s model entities | 16:04 |
| *** leecalcote has quit IRC | 16:04 | |
| gsagie_ | so i guess you want to model it-> service=network | 16:04 |
| irenab | what about namespaces isolation option? | 16:05 |
| apuimedo | gsagie_: yes, that's the simplest and more common use case we can support | 16:05 |
| gsagie_ | and then add routing between them, at first between all | 16:05 |
| irenab | we may consider pods (RC) to be on the same network regardless the service | 16:05 |
| apuimedo | irenab: I'm tempted to say that namespaces is something that I want to ignore for the time being | 16:06 |
| irenab | I think in some simple examples there are only Pods | 16:06 |
| apuimedo | in the sense that we would not isolate namespaces of the same tenant | 16:06 |
| apuimedo | but I'm not 80% on this | 16:06 |
| irenab | apuimedo: do we have multi-tenancy? | 16:06 |
| apuimedo | so I can be easily convinced | 16:06 |
| apuimedo | irenab: sort of xD | 16:06 |
| banix | well tenants don’t go across namespaces. no? | 16:07 |
| apuimedo | but now it relies on one host per tenant | 16:07 |
| gsagie_ | multi tenancy is just how you connect the relevant networks to a router | 16:07 |
| gsagie_ | i think | 16:07 |
| banix | nottalking about network namespaces | 16:07 |
| apuimedo | banix: no. exactly. But tenants could have several namespaces | 16:07 |
| *** leecalcote has joined #openstack-kuryr | 16:07 | |
| irenab | k8s namespaces | 16:07 |
| banix | wll are you talking about k8s namespace | 16:07 |
| banix | ok | 16:07 |
| apuimedo | I am talking to k8s namespaces, yes | 16:08 |
| apuimedo | irenab: I think that for multitenancy we will have to rely on the multitenancy that they are adding to k8s | 16:09 |
| irenab | so back to What, I think we should define scenarious to support, i.e. assuming all k8s namespace are not isolated | 16:09 |
| apuimedo | and somehow bundle authorization there | 16:09 |
| irenab | apuimedo: do you have any details on what is the k8s plan for multi-tenancy? | 16:09 |
| apuimedo | so that in etcd we can get the auth of the tenant that is associated to the service | 16:09 |
| apuimedo | and try to perform the neutron action with their auth | 16:10 |
| apuimedo | irenab: not in hand, no | 16:10 |
| irenab | apuimedo: this can be great, but we will need to manage tenants in keystone? | 16:10 |
| apuimedo | irenab: I was thinking something simpler | 16:10 |
| apuimedo | that somehow the creds would end up in etcd | 16:10 |
| irenab | assuming no multi-tenancy should be ok for now, agreee? | 16:10 |
| apuimedo | yes. without mulit-tenancy we should be ok | 16:11 |
| irenab | gsagie_: banix ? | 16:12 |
| apuimedo | hey, does any of you remember if it was possible to create an arbitrary token for a user in keystone? | 16:12 |
| banix | +1 | 16:12 |
| banix | apuimedo: 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 tenants | 16:12 |
| gsagie_ | credentials | 16:12 |
| gsagie_ | unless i didnt get something | 16:12 |
| gsagie_ | but i am not too familiar with the k8 namespaces yet | 16:13 |
| gsagie_ | but we can work without them at first | 16:13 |
| irenab | I think we need to see how to reflect this in neutron | 16:13 |
| apuimedo | I meant like oath token like k8s uses | 16:13 |
| gsagie_ | irenab: why this can't be different OS tenants? | 16:13 |
| gsagie_ | different Neutron tenants | 16:13 |
| banix | a tenant can create tokens at will but i am probably missing your point | 16:13 |
| irenab | gsagie_: who defines them and when? | 16:13 |
| apuimedo | oh | 16:14 |
| apuimedo | hey guys | 16:14 |
| apuimedo | and gals | 16:14 |
| apuimedo | k8s supports keystone auth | 16:14 |
| irenab | lets handle multi-tenancy for next phase | 16:14 |
| apuimedo | we may just require it | 16:14 |
| apuimedo | https://github.com/kubernetes/kubernetes/blob/master/docs/admin/authentication.md | 16:14 |
| irenab | apuimedo: cool | 16:14 |
| apuimedo | I'm not sure how big a handicap it will be for operators to accept keystone | 16:15 |
| apuimedo | but I'm sure big operators should be content with it | 16:15 |
| apuimedo | I'm betting openshift uses it | 16:15 |
| apuimedo | so we could say | 16:15 |
| apuimedo | if k8s keystone integration is configured it is multitenant, otherwise it is single tenant | 16:15 |
| apuimedo | for starters | 16:15 |
| apuimedo | #link https://github.com/kubernetes/kubernetes/blob/master/docs/admin/authentication.md | 16:16 |
| irenab | apuimedo: I think we need to verify the k8s approach for app multi-tenancy | 16: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 bits | 16:16 |
| irenab | apuimedo: this maybe related to the whole cluster | 16:16 |
| gsagie_ | if it integrates with keystone that would be great | 16:16 |
| apuimedo | #info | 16: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 binding | 16:17 |
| gsagie_ | yes challenge, we need to be able to keep the binding until neutron configuration has ended | 16:17 |
| apuimedo | gsagie_: banix: irenab: what about we create a blueprint with what we discussed | 16:18 |
| apuimedo | and as soon as it matures a bit we put it on a spec | 16:18 |
| apuimedo | completely WIP | 16:18 |
| banix | sounds good | 16:18 |
| gsagie_ | agreed! | 16:18 |
| irenab | gsagie_: we need to check contrail approach, I think they have similar components | 16:18 |
| apuimedo | or we can go straight for wip spec if you see fit | 16:18 |
| irenab | apuimedo: I will try to arrange initial draft version | 16:18 |
| apuimedo | as it seems people comment more on spec | 16:19 |
| apuimedo | irena: you just earned an extra cheese delivery | 16:19 |
| apuimedo | :-) | 16:19 |
| apuimedo | thanks! | 16:19 |
| irenab | apuimedo: :-) | 16:19 |
| apuimedo | #topic other | 16:19 |
| irenab | the last one was very good | 16:19 |
| apuimedo | that was extra :-) | 16:19 |
| apuimedo | anything else? | 16:19 |
| gsagie_ | :) | 16:20 |
| gsagie_ | somebody look at what contrail are doing | 16:20 |
| gsagie_ | i am fine doing it | 16:20 |
| apuimedo | I'm delivering catalan cheese straight from the farm :-) | 16:20 |
| apuimedo | gsagie_: if you can take a look at the etcd watcher, that'd be great | 16:20 |
| irenab | gsagie_:banix you better go for the cheese than T-bone | 16:20 |
| banix | :) | 16:21 |
| apuimedo | alright, so let's close up | 16:21 |
| apuimedo | #action irena to submit WIP spec | 16:21 |
| apuimedo | #action gsagie to look at contrail watcher | 16:21 |
| apuimedo | #endmeeting | 16:22 |
| openstack | Meeting ended Wed Feb 3 16:22:02 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:22 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/k8s_integration/2016/k8s_integration.2016-02-03-15.31.html | 16:22 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/k8s_integration/2016/k8s_integration.2016-02-03-15.31.txt | 16:22 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/k8s_integration/2016/k8s_integration.2016-02-03-15.31.log.html | 16:22 |
| apuimedo | Thanks a lot for joining folks! | 16:22 |
| gsagie_ | thanks all, thanks apuimedo for the great topics ;) | 16:22 |
| irenab | apuimedo: I meant blueprint :-) | 16:22 |
| apuimedo | :-) | 16:22 |
| apuimedo | irenab: too late, now it's in the minutes :D | 16:22 |
| apuimedo | •_•) | 16:22 |
| irenab | apuimedo: you will need to provide extra extra cheese delivery | 16:22 |
| apuimedo | ( •_•)>⌐■-■, | 16:22 |
| apuimedo | (⌐■_■) | 16:22 |
| apuimedo | we'll see what can be done | 16:23 |
| irenab | thanks guys, bye | 16:23 |
| apuimedo | they'll arrest you for smuggling | 16:23 |
| apuimedo | bye | 16:23 |
| *** shashank_hegde has joined #openstack-kuryr | 16:23 | |
| *** banix has quit IRC | 16:24 | |
| *** leecalcote has quit IRC | 16:30 | |
| *** gsagie_ has quit IRC | 16:33 | |
| *** mark_dunn has quit IRC | 17:08 | |
| apuimedo | gsagie: fkautz tells me that etcd watching is being closed down. Please, check the k8s watching apis | 17:08 |
| apuimedo | to see if they offer enough data for our net purposes or we need to contribute there | 17: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 |
| apuimedo | salv-orl_: very well, ask if you need any clarification | 17:10 |
| salv-orl_ | apuimedo: will do thanks | 17:11 |
| apuimedo | ;-) | 17:13 |
| *** devvesa has joined #openstack-kuryr | 17:42 | |
| *** shashank_hegde has quit IRC | 17:50 | |
| *** banix has joined #openstack-kuryr | 18:07 | |
| *** devvesa has quit IRC | 18:12 | |
| *** shashank_hegde has joined #openstack-kuryr | 18:14 | |
| *** apuimedo has quit IRC | 18:57 | |
| banix | gsagie: irenab mestery apuimedo Added Kuryr as a docker plugin to the docker docs here: https://github.com/docker/docker/pull/19976 | 19:33 |
| mestery | banix: You rock my friend :) | 20:32 |
| *** salv-orlando has joined #openstack-kuryr | 21:54 | |
| *** salv-orl_ has quit IRC | 21:56 | |
| *** banix has quit IRC | 22:26 | |
| *** yuanying has quit IRC | 23:54 | |
| *** yuanying has joined #openstack-kuryr | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!