I'm running openvswitch on my laptop to manage networking to a number of libvirt/KVM VMs I use on it from time to time. Recently the package was upgraded from OVS version 1.4.1 to version 1.6.1. After the upgrade my networking stopped working. It turned out this was due to the database schema changing between 1.4.1 and 1.6.1. In the packaging in the project repos they verify the DB schema is correct in the init scripts before starting ovsdb-server, upgrading if neccessary. The code for doing this is somewhat buried in the generic library supporting the different platforms for which the project itself provides integration. You can find the actual upgrade code here: http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=utilities/ovs-ctl.in;h=552cef3781c621fa02356acb0dc87b3fdaa8cc56;hb=HEAD#l83 The code calling this is here: http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=utilities/ovs-ctl.in;h=552cef3781c621fa02356acb0dc87b3fdaa8cc56;hb=HEAD#l170 Reproducible: Always Steps to Reproduce: 1. Install openvswitch 1.4.1 2. Create some bridges & ports 3. Upgrade to openvswitch 1.6.1 4. Verify that for example bridge interfaces don't show up in the output of ifconfig. For example, if you have a bridge named mybr0 you should have an interface named mybr0 in the ifconfig output. Alternatively, verify that packets are not being forwarded between ports on the bridges as expected. Actual Results: The openvswitch daemons (ovsdb-server & ovs-vswitchd) do not start properly and do not setup the networking configuration expected. Expected Results: Ideally the database schema should be ugpraded and the openvswitch daemons should work correctly. The package contains instructions for creating an initially empty database using "emerge --config". The implementation of this does not handle updating an existing database and gives an error in that case. One method of handling this would be to have the "emerge --config" implementation upgrade an existing database if it exists and modifying the message printed postinst to explain what to do. However, based on the project's provided packaging for Debian and RedHat it seems clear the intention is to have the init scripts automatically perform these types of upgrades so that the manual migration steps are minimized.
What Gentoo category/package are we talking about, here?
well, automagic is not what we do in Gentoo. But adding that functionality to pkg_config is probably a good idea. Will look into it.
Sounds good. I'd be happy to try out the changes by downgrading and re-upgrading Right now I can easily recreate the configuration manually if something goes wrong during the upgrade since I just had to do it. ;-)
Done in 1.6.1-r1.
I retested following the instructions and everything went smoothly. Thanks for the updated instructions!
