netplan-developers team mailing list archive

[Lukas Märdian <lukas.maerdian@xxxxxxxxxxxxx>]

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

> - 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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature