Thanks Guru! Some comments inline.
Salvatore On 19 May 2016 at 16:11, Guru Shetty <g...@ovn.org> wrote: > > > On 19 May 2016 at 03:57, Salvatore Orlando <salv.orla...@gmail.com> wrote: > >> [Accidentally sent message before completing, resuming here] >> >> Hello, >> >> I have been working for a while on integration with kubernetes with a CNI >> plugin for OVN. >> The work in [1] is forked by Guru's repository by the same name [2]. >> >> Most consumers of the CNI interface have an expectation that when >> returning >> from the plugin the container interface is fully configured and ready to >> send/receive data. >> For the OVN case this means that when returning from the CNI both VIF >> plugging and logical configuration (lport and ACLs) must be completed. >> >> However, in the current implementation logical port management was moved >> out of the plugin [3] in order to avoid calling into the OVN NB Database. >> This means that in order to fulfil the "network ready" expectation there's >> a need for adding a synchronisation point in the CNI plugin (ie: a >> blocking >> call waiting for a "ready" event). >> >> At this stage I am wondering whether it might be actually better to revert >> to the previous state - where logical port creation was performed in the >> plugin [4]. >> > The disadvantage of moving it back would be that we now need to provide a > way for the plugins to securely talk to OVN NB. This in itself is not a big > deal for the "overlay" mode for a single tenant as we have ssl support. But > this will become a problem for multi-tenancy as now a container breakout > would essentially have full control over your network. > Indeed it does. That's the reason why I reworked the plugin in the first place after all. Unfortunately that's probably not how CNI is meant to work. Moreover Kubernetes will eventually introduce multitenancy and therefore the same problem might apply also to the overlay case. While authorization is probably out of scope for OVN, would it be crazy to have a token mechanism (or something similar) that will allow a ovn-northd client to execute a single ovsdb transaction? (a sort of one-time password if you want). Or a system to limit a client visibility only a given chassis? I am thinkng aloud here and I do realize there's a certain degree of lunacy in my statements. I'm just trying to rule out all the other options that would make a more natural fit for CNI integration. > > So, ideally your current model is better. The plugins have access to k8s > API server itself. So one way to synchronize is to pass the ready event via > a pod annotation? You probably have better ideas. > I unfortunately do not have a better idea, that's why opinions are welcome! Waiting on a "ready" event will work and is likely to be the best thing we can do at the moment; however adding blocking call which introduces a synchronisation point via the k8s API server is still not ideal. > > > >> I am wondering whether it might be fair to expect ovn-northd to be >> accessible from the control plane. What is your opinion? >> >> Should that be the way to go, the CNI plugin should also take care of >> implementing ACLs before returning (not just applying a drop-all rule as >> it >> does now [5]) - because otherwise networking configuration would not be >> complete (especially with a drop-all rule!). >> >> Salvatore >> >> [1] https://github.com/salv-orlando/ovn-kubernetes >> [2] https://github.com/shettyg/ovn-kubernetes >> [3] >> >> https://github.com/salv-orlando/ovn-kubernetes/commit/b951079fe3100160478f0cbc0eaf6729c088a4af >> [4] >> >> https://github.com/salv-orlando/ovn-kubernetes/blob/78c7b39715894cfa64066b294a80f55d2c01e356/bin/ovn_cni.py#L191 >> [5] >> >> https://github.com/salv-orlando/ovn-kubernetes/blob/master/ovn_k8s/conn_processor.py#L59 >> >> >> >> >> >> >> On 19 May 2016 at 12:38, Salvatore Orlando <salv.orla...@gmail.com> >> wrote: >> >> > Hello, >> > >> > I have been working for a while on integration with kubernetes with a >> CNI >> > plugin for OVN. >> > The work in [1] is forked by Guru's repository by the same name [2]. >> > >> > Most consumers of the CNI interface have an expectation that when >> > returning from the plugin the container interface is fully configured >> and >> > ready to send/receive data. >> > For the OVN >> > >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> http://openvswitch.org/mailman/listinfo/dev >> > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
