| *** yamamoto has joined #openstack-kuryr | 00:03 | |
| *** yamamoto has quit IRC | 00:10 | |
| *** yamamoto has joined #openstack-kuryr | 00:34 | |
| *** yamamoto has quit IRC | 00:35 | |
| openstackgerrit | Frederick F. Kautz IV proposed openstack/kuryr: plugin.sh stops docker service rather than kill docker daemon. https://review.openstack.org/282804 | 01:04 |
|---|---|---|
| *** salv-orlando has joined #openstack-kuryr | 01:20 | |
| *** salv-orlando has quit IRC | 01:30 | |
| *** yamamoto has joined #openstack-kuryr | 01:36 | |
| *** yamamoto has quit IRC | 01:44 | |
| *** irenab has joined #openstack-kuryr | 03:22 | |
| *** irenab_ has quit IRC | 03:24 | |
| *** salv-orlando has joined #openstack-kuryr | 03:26 | |
| *** salv-orlando has quit IRC | 03:38 | |
| *** salv-orlando has joined #openstack-kuryr | 04:00 | |
| *** salv-orlando has quit IRC | 04:09 | |
| *** salv-orlando has joined #openstack-kuryr | 05:09 | |
| *** salv-orlando has quit IRC | 05:14 | |
| *** salv-orlando has joined #openstack-kuryr | 05:31 | |
| *** salv-orlando has quit IRC | 05:38 | |
| *** salv-orlando has joined #openstack-kuryr | 06:00 | |
| *** salv-orlando has quit IRC | 06:07 | |
| *** yamamoto has joined #openstack-kuryr | 06:07 | |
| *** salv-orlando has joined #openstack-kuryr | 06:13 | |
| *** salv-orlando has quit IRC | 06:23 | |
| *** yamamoto has quit IRC | 06:32 | |
| *** salv-orlando has joined #openstack-kuryr | 07:23 | |
| *** salv-orlando has quit IRC | 07:33 | |
| *** yamamoto has joined #openstack-kuryr | 07:33 | |
| *** gsagie has joined #openstack-kuryr | 07:36 | |
| *** yamamoto has quit IRC | 07:39 | |
| *** yamamoto has joined #openstack-kuryr | 08:24 | |
| *** yamamoto has quit IRC | 08:28 | |
| *** apuimedo has joined #openstack-kuryr | 08:56 | |
| apuimedo | morning | 08:56 |
| gsagie | hi | 08:57 |
| *** shashank_hegde has quit IRC | 09:02 | |
| apuimedo | gsagie: irenab: Last night I had a thought about nested COE integration. Maybe it is obvious to the two of you, but I hadn't thought of it that way before | 09:08 |
| apuimedo | One of my goals was always to limit access to the management network from the VMs, since they are owned by tenants | 09:08 |
| apuimedo | then I was saying that we could probably do fine if we just gave acces to the management network to the VMs that run the k8s controller, for example | 09:09 |
| apuimedo | and that is certainly more limited and probably better | 09:10 |
| apuimedo | but my latest thought is this | 09:10 |
| *** dingboopt has joined #openstack-kuryr | 09:10 | |
| apuimedo | just like there is a port in the VM network for the DHCP server, there is going to be a port for the API watcher | 09:10 |
| apuimedo | so that it can peek at the k8s API, but it will only be for ingressing into the VM (and established connections) | 09:11 |
| apuimedo | So for the reference implementation we'll have a namespace somewhere where OVS binds a port to the VM network of the k8s magnum bay model | 09:11 |
| apuimedo | and in that namespace, the API watcher is run | 09:12 |
| apuimedo | gsagie: irenab: what do you think? | 09:12 |
| irenab | apuimedo: reading | 09:13 |
| apuimedo | thanks | 09:14 |
| irenab | apuimedo: it makes sense to me, assuming I understood what you had in mind | 09:16 |
| apuimedo | irenab: if you have any question, ask ;-) | 09:18 |
| irenab | having diagram could be helpful :-) | 09:18 |
| irenab | but in general, I think API watcher could be considered as yet another kube controller component, so it will be on kube management network and it should be able to access openstack management network | 09:21 |
| apuimedo | irenab: yes, my point is that it does not need to sit on the bay VMs, that it can be on the compute nodes themselves or in a separate machine | 09:23 |
| apuimedo | it only needs a namespace with, as you said, a port to the k8s kingdom and one to the management network | 09:23 |
| irenab | apuimedo: namespace here is linux namspace 9pod) not k8s namspace, right? | 09:24 |
| apuimedo | right | 09:26 |
| apuimedo | Bloody overloading of the namespace term in k8s... | 09:26 |
| irenab | I think it probably need to be in the kube-system namespace, not sure how access authorization will work for outside the bay, but networking wise seems ok | 09:27 |
| *** yamamoto has joined #openstack-kuryr | 09:28 | |
| *** yamamoto has quit IRC | 09:35 | |
| *** salv-orlando has joined #openstack-kuryr | 09:40 | |
| *** salv-orlando has quit IRC | 09:43 | |
| *** salv-orlando has joined #openstack-kuryr | 09:55 | |
| *** yamamoto has joined #openstack-kuryr | 09:55 | |
| *** salv-orlando has quit IRC | 10:02 | |
| *** yamamoto has joined #openstack-kuryr | 10:56 | |
| gsagie | apuimedo: i believe that we agreed that this is the goal and the local plugin only does the binding | 10:58 |
| apuimedo | gsagie: yes, we did agree on the goal | 10:58 |
| gsagie | apuimedo: either way each VM has to have some network connected to the "managment" network as kubelet needs to communicate | 10:58 |
| gsagie | with the master | 10:58 |
| apuimedo | the management of k8s yes, not the management of OSt | 10:59 |
| gsagie | but in terms of Neutron, i think only the master VM that has our watcher service needs to have access to | 10:59 |
| gsagie | the hard part which i was talking with Taku and Irena last week, is how to synchronize them, apparently contrail does a sleep of 30 seconds in the plugin | 10:59 |
| apuimedo | What I am saying above is that the watcher does not need to be in the VM | 11:00 |
| apuimedo | it can be running on any compute or network node in the OSt deployment | 11:01 |
| gsagie | i was hoping to achieve this by having our watcher be able to re-trigger the API and make kubelet re-call the plugin | 11:01 |
| gsagie | apuimedo: yeah i like that idea :) it makes it "service like" | 11:01 |
| apuimedo | so the VM doesn't need any access to the OST management network where the Neutron API is | 11:01 |
| gsagie | yeah agreed :) thats a good solution | 11:01 |
| apuimedo | gsagie: I'll try to look at the sync thing more this week | 11:01 |
| gsagie | apuimedo: but the watcher must have route to the namespace | 11:02 |
| gsagie | to the Kubernetes master VM that is | 11:02 |
| apuimedo | gsagie: not necessarily, it can just have a port on each network | 11:03 |
| apuimedo | and not have any forwarding/routing capabilities | 11:03 |
| *** yamamoto has quit IRC | 11:03 | |
| gsagie | apuimedo: i was thinking about sending the sync question to the Kubernetes mailing list, i have actually read that you can call Kubelet API directly as well, so i wonder if we can somehow force Kubelete to re-call the plugin with all the additional data | 11:03 |
| gsagie | that our watcher service added on the container after it builded everything in Neutron | 11:04 |
| gsagie | if that make sense | 11:04 |
| gsagie | so our CNI plugin does nothing unless it sees a specific annotation on the container that means eveyrthing is ready from Neutron | 11:04 |
| apuimedo | I'd like to avoid re-triggering, but I don't have an answer yet for what we could do | 11:04 |
| apuimedo | gsagie: sure, the CNI plugin will only do something if it sees certain data | 11:05 |
| gsagie | the other approach is to just let the CNI "store" these actions and wait until it has enough information | 11:05 |
| gsagie | temp solution could be to write it to local file or something like that, or use the K/V | 11:05 |
| *** yamamoto has joined #openstack-kuryr | 11:06 | |
| *** yamamoto has quit IRC | 11:06 | |
| *** yamamoto has joined #openstack-kuryr | 11:08 | |
| gsagie | apuimedo: i really like this thinking thought, the less constraint we impose on the user the better the solution is going to be | 11:34 |
| *** apuimedo has quit IRC | 11:42 | |
| *** apuimedo has joined #openstack-kuryr | 12:03 | |
| *** salv-orlando has joined #openstack-kuryr | 12:09 | |
| *** salv-orlando has quit IRC | 12:16 | |
| irenab | gsagie: I am a bit uncomfortable with imposing the dependency you describe. I think we should use k8s ways to achive the flow that allows api-watcher to handle neutron calls and CNI driver to serve local binding. Did you have a chance to check if adding annotation on Pod re-triger kubelet Setup? | 12:21 |
| *** dingboopt has quit IRC | 12:37 | |
| *** yamamoto has quit IRC | 12:52 | |
| *** salv-orlando has joined #openstack-kuryr | 13:20 | |
| *** salv-orlando has quit IRC | 13:27 | |
| *** kexiaodong has quit IRC | 13:30 | |
| *** yamamoto has joined #openstack-kuryr | 13:52 | |
| *** yamamoto has quit IRC | 13:59 | |
| *** salv-orlando has joined #openstack-kuryr | 14:44 | |
| *** salv-orlando has quit IRC | 14:49 | |
| *** salv-orlando has joined #openstack-kuryr | 16:03 | |
| *** salv-orlando has quit IRC | 16:07 | |
| *** salv-orlando has joined #openstack-kuryr | 17:07 | |
| *** salv-orlando has quit IRC | 17:17 | |
| *** salv-orlando has joined #openstack-kuryr | 17:40 | |
| *** salv-orlando has quit IRC | 17:54 | |
| fkautz | gsagie: for https://review.openstack.org/#/c/282804/ if we write out to the docker config, we'll probably need to remove the modifications on unstack | 18:00 |
| *** shashank_hegde has joined #openstack-kuryr | 18:39 | |
| *** salv-orlando has joined #openstack-kuryr | 19:35 | |
| *** salv-orlando has quit IRC | 19:42 | |
| *** salv-orlando has joined #openstack-kuryr | 20:35 | |
| *** salv-orlando has quit IRC | 20:43 | |
| *** salv-orlando has joined #openstack-kuryr | 21:33 | |
| *** srampal has joined #openstack-kuryr | 22:27 | |
| *** srampal has quit IRC | 22:34 | |
| *** banix has joined #openstack-kuryr | 23:22 | |
| *** yuanying has joined #openstack-kuryr | 23:26 | |
| *** shashank_hegde has quit IRC | 23:46 | |
| *** banix has quit IRC | 23:55 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!