lack of openvswitch support

Ryan, no, I'm sorry, but the tag uosci does not apply to this bug, though it may be a separate additional issue with netplan. This has nothing to do with charms, juju, or openstack.

Yes, we want to track this task against the charm and with the tag for other reasons. That is not to say that the task against netplan is valid/invalid. Both can be tasked to this bug. Thank you.

Fair enough, wanted to make sure focus wasn't focused on the charm or openstack, as neither are used.

AFAIK the neutron-openvswitch charm does not actually make use of /e/n/i or netplan so marking the charm bug task as incomplete/low pending further clarification of impact onto the neutron-openvswitch charm.

It is possible to use Open vSwitch -- after boot, run: ifconfig eno2 up ... Open vSwitch will use its stored configuration and simply carry on as if nothing happened. But there is no way to simply set an interface as administratively up using netplan (or so it seems) and allow Open vSwitch to start up as in previous versions of Ubuntu.

We are getting ready for Ubuntu 18.04 and it seems like this is a pretty serious issue. We run all of our VM environments using Open vSwitch, and this will cause us to change our entire approach.

There's always clunky workarounds, but these things need to be supported out of the box. (Or simply drop all Open vSwitch from Ubuntu and force us to use netplan bridges.)

How could I accomplish the same as Ubuntu 16.04's "iface eno2 inet manual" using netplan?

We are currently using an undesirable hack to accomplish this. A cron task:

@reboot /sbin/ifconfig eno2 up >/dev/null 2>&1

Not idea.

On the charm, we need to confirm netplan impact/to-dos regarding use of add_ovsbridge_linuxbridge via the charm's data-port ("ovs-bridge:linuxbridge) config option and use case.

https://github.com/openstack/charm-neutron-openvswitch/blob/9cd483e653303d904f3e34d36a2c5b14000556ce/hooks/charmhelpers/contrib/network/ovs/__init__.py#L105

For background, that feature was added via http://bugs.launchpad.net/bugs/1635067.

Clarity on #7: It is Bionic-Queens (Netplan only by default) that we need to exercise and assess.

So it seems Netplan still lacks OpenvSwitch support _and_ the ability to bring an interface administratively up at server boot. Why is it the default for new installations?

If it may help, I workaround that issue by declaring the interface with a single random IPv6 link-local address.

eth0:
  addresses:
    - fe80::abcd:1234:…

So it looks like there is no support in networkd for ovs: https://github.com/systemd/systemd/issues/2613

There is limited support in NM: https://developer.gnome.org/NetworkManager/unstable/nm-openvswitch.html - I don't know if that's landed in a release yet.

So this looks like it would probably require either networkmanager, which most servers don't usually install, or its own backend. That would be awkward too: netplan is run at boot as a systemd generator - a short running one-shot process. It's not its own part of the boot process (it's not a systemd unit), and it's definitely not as a long-running daemon.

We're also going to have to deal with the fact that OVS config is automatically persistent, which is also different to the way netplan does things (making ephemeral files and putting them in /run). You can recover almost any netplan issue by making sure the YAML is valid and rebooting; this stops being true with OVS.

This will require some proper design and thought.

I do not think that we necessarily need OpenVSwitch support in netplan.io. As daxtens pointed out, OpenVSwitch uses a persistent configuration database and thus does not fit well into the concept of netplan.io anyway.

I think it is okay, if OpenVSwitch needs to be configured through its own channels (ovs-vsctl). The main problem at the moment is that netplan.io does not provide a way to bring an interface up without configuring an address for that interface. However, if an interface is part of an OpenVSwitch bridge, it needs to be brought up in order for the bridge to work as expected.

In systemd-networkd, this can easily be solved by adding a configuration file like the following:

[Match]
Name=eth0

[Network]
DHCP=no
IPv6AcceptRA=no
LinkLocalAddressing=no

In this example, the configuration is for eth0, but of course this will work for other interfaces too. What we really need in my opinion is a way to tell netplan.io that it shall generate such a configuration file.

The first step would be generating a configuration file, even if DHCPv4 and DHCPv6 are disabled, no RAs are accepted, and there is no static address either. This would only leave the "LinkLocalAddressing" option as a new feature because netplan.io does currently not provide a matching option.

Does anyone know whether the same functionality can also be achieved with NetworkManager as the backend?

Hi,

Yes, on further consideration I agree with this approach. I don't know
what the current status of bringing an interface up in netplan is - I
know support for anonymous bridges was recently fixed so hopefully
this is a pretty straight-forward extension of that.

Regards,
Daniel

The netplan implementation is being worked on here:
https://github.com/CanonicalLtd/netplan/pull/154

Initial support has been released with netplan.io 0.100-0ubuntu4