lack of openvswitch support

Bug #1728134 reported by James Gibbins
144
This bug affects 29 people
Affects Status Importance Assigned to Milestone
Netplan
Fix Released
High
Unassigned
OpenStack Neutron Open vSwitch Charm
Triaged
Medium
Unassigned

Bug Description

title sums it up, no ability to use with openvswitch, /etc/network/interfaces handles this just fine.

Tags: uosci

Related branches

Ryan Beisner (1chb1n)
tags: added: uosci
Revision history for this message
James Gibbins (jfgibbins) wrote :

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.

Revision history for this message
Ryan Beisner (1chb1n) wrote :

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.

Revision history for this message
James Gibbins (jfgibbins) wrote :

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

Revision history for this message
James Page (james-page) wrote :

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.

Changed in charm-neutron-openvswitch:
status: New → Incomplete
importance: Undecided → Low
Revision history for this message
Laz Peterson (laz-v) wrote :

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?

Revision history for this message
Laz Peterson (laz-v) wrote :

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

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

Not idea.

Revision history for this message
Ryan Beisner (1chb1n) wrote :

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.

Revision history for this message
Ryan Beisner (1chb1n) wrote :

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

Changed in charm-neutron-openvswitch:
status: Incomplete → New
milestone: none → 18.02
importance: Low → High
James Page (james-page)
Changed in charm-neutron-openvswitch:
status: New → Triaged
importance: High → Medium
Ryan Beisner (1chb1n)
Changed in charm-neutron-openvswitch:
milestone: 18.02 → 18.05
David Ames (thedac)
Changed in charm-neutron-openvswitch:
milestone: 18.05 → 18.08
Revision history for this message
Mikko Tanner (shapemaker) wrote :

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?

Revision history for this message
Jean-Daniel Dupas (xooloo) wrote :

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

Revision history for this message
Daniel Axtens (daxtens) wrote :

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.

James Page (james-page)
Changed in charm-neutron-openvswitch:
milestone: 18.08 → 18.11
Revision history for this message
Sebastian Marsching (sebastian-marsching) wrote :

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?

Revision history for this message
Daniel Axtens (daxtens) wrote : Re: [Bug 1728134] Re: lack of openvswitch support

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

David Ames (thedac)
Changed in charm-neutron-openvswitch:
milestone: 18.11 → 19.04
David Ames (thedac)
Changed in charm-neutron-openvswitch:
milestone: 19.04 → 19.07
David Ames (thedac)
Changed in charm-neutron-openvswitch:
milestone: 19.07 → 19.10
David Ames (thedac)
Changed in charm-neutron-openvswitch:
milestone: 19.10 → 20.01
James Page (james-page)
Changed in charm-neutron-openvswitch:
milestone: 20.01 → 20.05
David Ames (thedac)
Changed in charm-neutron-openvswitch:
milestone: 20.05 → 20.08
James Page (james-page)
Changed in charm-neutron-openvswitch:
milestone: 20.08 → none
Changed in netplan:
status: New → In Progress
importance: Undecided → High
Revision history for this message
Lukas Märdian (slyon) wrote :

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

Revision history for this message
Lukas Märdian (slyon) wrote :

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

Changed in netplan:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.