I'm leaning towards just using the interfaces stanza after spending a bit more time looking at the code. I initially made the incorrect assumption based off the VLAN definition that ports needed to know their parent bridge. However, it looks like OVS bonds handle the bridge<->port mapping without explicitly knowing their parent bridge and OVS bonds also already have the logic to error out if a bridge doesn't claim them as a member. I think I can use bonds as a good reference.
In terms of schema change, I believe the only things that would need to change is allowing for tunnels (some tunnels?) to have a openvswitch key and, if they are OVS-flavored, to make "local" (the local tunnel IP) not required. I have never specified local_ip while making a OVS GRE tunnel so it might even have to be explicitly absent. This one will take me a bit as my C is rusty. Do you prefer WIP PRs or just a PR once it's viable? - Brian On Tue, Feb 8, 2022 at 9:53 AM Lukas Märdian <[email protected]> wrote: > > +CC Steve, for schema review > > > Hi Brian, > > Am 08.02.22 um 00:24 schrieb Brian Turek: > > Greetings, > > > > I've been experimenting using netplan to control Open vSwitch (OVS) > > bridges/interfaces and am wondering if there is any appetite to add > > support for gretap tunnels via native OVS commands? It's a little > > tricky to implement as the interface *must* be attached to an OVS > > bridge and it does not appear that there is a fool-proof method of > > linking a tunnel to a bridge. For example, VLAN interfaces have the > > "link" attribute whereas the only existing method of linking a tunnel > > would be via the bridge's "interfaces" attribute. > As you already found, we're currently supporting (basic) configuration > of OVS as well as setting up GRE tunnels. So the combination of both > (GRE on top of OVS, e.g. for offloading) would definitely make sense and > improve our overall Open vSwitch offering. If you want to work on that, > that would be appreciated! > > I looked through the netplan code to see if there was any way to abuse > > the "other-config" attribute to get this to work but the "add-port" > > method of ovs-vsctl is gated solely behind patch ports. > > > > I'm willing to spend some time trying to implement this (I submitted 2 > > minor patches recently!) but am looking for some direction on how to > > firmly establish the br<->tunnel linkage before beginning. > > Thanks for that! I really liked the two PRs that you've submitted > recently – nicely structured and good test coverage! > > As you mentioned above using the bridge's "interfaces" stanza to link a > GRE tunnel would be one way of doing it that does not need > changes/additions to the YAML schema. That could work as we can deduce > when a tunnel is an interface to an OVS bridge (i.e. has some > "openvswitch": {} settings) and handle that implicitly. But I agree that > this isn't fool-proof and could be confused easily. > > Another idea that comes to mind would be to add a new "openvswitch": { > "link": "ovs-br0" } stanza to a tunnel definition. This YAML schema > would show explicitly that this is an "OVS-tunnel" that is liked to a > given (OVS-)bridge. What do you think about that? > > We usually want to consult Steve for such schema definitions, so I've > put him on CC. > > Cheers, > > Lukas > > > > > - Brian -- Mailing list: https://launchpad.net/~netplan-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~netplan-developers More help : https://help.launchpad.net/ListHelp
