Hi Lukas, I submitted a WIP PR a few days ago (https://github.com/canonical/netplan/pull/261) that has working GRETAP support for OVS. I'm not quite sure the best communication medium so I'll copy my questions included in the PR below:
- OVS calls GRE tunnels between two bridges just gre tunnels. However, in the semantics of netplan, it is actually a gretap tunnel (i.e. it's putting layer 2 packets through a GRE tunnel). I went with calling these gretap/ip6gretap tunnels as I feel it's technically correct but I also think this is going to cause confusion. Thoughts? - For all tunnel types, the local_ip is a required YAML key but it's really optional for most tunnels. Is it OK to remove the required check on it? I'm happy to tweak the affected tests. - I opted for OVS-flavored bridges to make any attached gretap/ip6gretap tunnels inherit being OVS controlled. I don't have a firm understanding on the order in which interfaces are parsed so am unsure if this method works every time or is dependent on interface order. - This raises a secondary question about OVS bonds: if a bond detects one of its members being OVS, it then switches its back-end to OVS. However, I didn't see any code to make a bridge containing a now OVS bond to then become OVS. - Brian On Wed, Feb 9, 2022 at 10:54 AM Lukas Märdian <[email protected]> wrote: > > Hey Brian! > > Am 09.02.22 um 13:22 schrieb Brian Turek: > > 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. > > Sure, that's certainly a viable option. Using existing schema > definitions is always a nice way to handle new features, we just need to > make sure to update the documentation/reference (netplan.md) to describe > the new cases. > > > 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. > > It shouldn't be a problem to extend the existing "openvswitch": {...} > stanza to tunnels. To check for the tunnel type and local IP conditions > you can make use of the validation.c module. > > > 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? > > Cool, I'm looking forward to your PR! We usually submit "Draft" PRs on > Github as soon as we have something presentable, then once it's done > switch it over to the "Ready for review" state. In the meantime, feel > free to ping people on this mailing list or on IRC in #netplan on > libera.chat. > > Cheers, > Lukas > -- Mailing list: https://launchpad.net/~netplan-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~netplan-developers More help : https://help.launchpad.net/ListHelp
