netplan-developers team mailing list archive

[Brian Turek <brian.turek@xxxxxxxxx>]

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
<lukas.maerdian@xxxxxxxxxxxxx> 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
>