Open vSwitch: Do not fail to add node when the ovs_name or ovs_link already exists

[mbakke]

gnt-node add will unconditionally attempt to create the switch and connect the uplink specified in the node group. It is possible that the switch is already configured by external tools. This PR makes it not fail when that is the case.

[saschalucas]

Thanks for your improvement.

Actually I tried to understand the openvswitch design of Ganeti. What I've found are undocumented cluster/group/node parameters ovs, ovs_link, ovs_name (correct me if I'm wrong). However I could reproduce the problem, which also occur at gnt-node add --readd.

All other network modes rely on external setup, probably ovs should do the same? But this an other story.

[mbakke]

Thanks for checking.

It would make sense for Ganeti to assume that the OVS bridge is already configured and not cleverly try to create it. I think then the ovs_link parameter can be removed too, simplifying things for administrators. In practice the uplink is usually a bond created with ovs-appctl anyway.

I'll make a mental TODO to simplify and document the OVS stuff. :-)

[iustin]

Not so sure about that. Ganeti's principle is that it will usually configure things as needed, and not require the admin to do extra manual work...

Of course, this does not always apply - I mention this as a general principle, for ovs maybe it makes more sense to do it this way.

[mbakke]

Right, thanks for the input. I don't have a strong opinion, I just remember being thorougly confused between the distinction of ovs_link vs ovs_name back in the day. ovs_link is typically a node-specific interface such as eno1 that is connected to the outside world, whereas ovs_name is the bridge name -- it does not help that the link NIC parameter corresponds to ovs_name.

Probably the best course of action will reveal itself just by documenting this stuff. :-)

[rbott]

...which brings me to another point: I would like to include OVS configurations in automated testings of Ganeti but I have no clue about it at all. Would it be possible to share your configuration e.g. to the ganeti mailing list (or to me directly)? That way we could a) extend current Ganeti test environments to support & test OVS and b) also add documentation to Ganeti itself on how to setup and use OVS.

[mbakke]

@rbott sounds great! I'll document three different scenarios here, each creating an OVS brige named br0, and an "access interface" for the node called ovs0. The access interface can be used as a regular interface, similar to adding an IP on a bridge interface.

1. single uplink eth0, no VLANs, ovs0 on the native network

ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0 vlan_mode=native-untagged
ovs-vsctl add-port br0 ovs0 vlan_mode=native-untagged -- set Interface ovs0 type=internal

2. single uplink eth0, tagged VLANs, ovs0 on VLAN 1

ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
ovs-vsctl add-port br0 ovs0 tag=1 -- set Interface ovs0 type=internal

3. bonded interfaces eth0 and eth1, tagged VLANs 100,200,300 only, ovs0 on VLAN100

ovs-vsctl add-br br0
ovs-vsctl add-bond br0 eth0 eth1 bond_mode=balance-tcp lacp=active trunks=100,200,300
ovs-vsctl add-port br0 ovs0 tag=100 -- set Interface ovs0 type=internal

I'm currently writing a blog post on how to run Ganeti with OVS on GNU Guix, which I'll run by the mailing list in a few days. It only covers scenario 1 here though.

[mbakke]

I should mention that such an "access interface" is only really necessary if the node needs an IP on eth0 itself.

I tend to create a gnt0 for use as master_netdev unless another network is available.