Arch Linux

Is there a reason not to delete the interface in openvswitch_down?
Apart from that, it looks good.

I did wonder about that. It's useful to clean things up for testing (removes unwanted interfaces) but it has little value for a stable / production environment.

Please feel free to remove the deletion code in down(). I have no strong opinion either way.

openvswitch_down() {
for ovs_client in "${BindsToInterfaces[@]}"; do
ip link set "$ovs_client" promisc off down
done
ip_unset
bring_interface_down "$Interface"
}


-jonathan

I was thinking about the bridge interface (ovs-br0 in the example). The rationale would be that a start/stop cycle should leave as little trace as possible. I know that 'start' doesn't necessarily create the bridge interface, but it still feels sane to delete it on 'stop': the fact that we never bind to the bridge interface suggests that netctl is responsible for its creation.

I'm sorry to bring this nitpicking up, but this is precisely the stuff that I am no expert on in the openvswitch case (i.e. what are the deletion commands and their side-effects).

Jouke,

I am no expert on the matter, just a user for the single use case of a bridged interface for some lxc containers and libvirtd VMs. Assuming no deletion, once the device is in the openvswitch db, then the bridge will be instantiated (I assume) by the openvswitch module and then netctl just brings it up. Thus without the deletion command, once the bridge was defined in the ovs-db, it would always be instantiated (but not brought up) by loading the kernel module.

I don't think there is a perfect solution, but deletion on down is (IMHO) cleaner; we cannot cleanly detect if the bridge was extant or we created it. I'm sorry I don't feel qualified to provide a more definitive view.

-jonathan

I installed openvswitch to do some testing myself.
This is what I had in mind:

openvswitch_down() {
for ovs_client in "${BindsToInterfaces[@]}"; do
ip link set "$ovs_client" promisc off down
done
ip_unset
$OVSCTL del-br "$Interface"
}

Any comments on that?
Additionally, I found that the ovs-vswitchd systemd service has to be running before the $OVSCTL is usable. Is this correct? If so, we need to find a way to specify this dependency.

That works fine.

You are correct on the dependency. I've (perhaps luckily) never seen a problem, but I appreciate there could be one.

How about this?

Excellent. I think we have a winner!

-jonathan