netplan-developers team mailing list archive

[Brian Turek <brian.turek@xxxxxxxxx>]

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