> Why doesn't it work? Whenever the configuration needs to set (either > for a new device or to change the config), parse needs to be called. > If it returns an error at that point, the operation will fail, as it > should, and the previous state will remain. This is different from > the current situation where we allow an invalid config initially and > then later fail to handle the exact same config.
It works in the majority of cases, there is one specific race (possibly rare) in which it doesn't work. Perhaps we can ignore this case altogether: 1) vport is create with proper configuration. 2) ovs-vswitchd dies for some reason 3) an unsupported configuration option is added to the vport in the database 4) vswitchd comes back up Simply returning EINVAL in parse_tunnel_config won't fix the problem in this case, because netdev_dev_args_equal() is going to fail before netdev_dev->netdev_class->open() has a chance to call parse_tunnel_config(). That said, this is pretty edge case-ish, perhaps it's not worth all the extra code to catch it. > I think there's a more generic problem here that bridge.c simply > doesn't handle changes to the config when ovs-vswitchd isn't running. > Ports will get enumerated and netdev_open() will get called on them > with the new configuration. However, this configuration normally gets > passed down to the kernel when the ports are added but this won't > happen since they already exist. netdev_set_config() also doesn't get > called because the netdevs are being opened for the first time. The > end result is that netdev_open() chokes because ofproto has already > opened the port with the kernel config. Yes, this is exactly the problem. > Perhaps if we just reconfigured ports at ovs-vswitchd startup then we > could avoid this whole issue by not needing to do argument comparison > at all. I'd be in favor of a solution like that. Seems cleaner. I'd suggest that in the short term (meaning today) I'll write a patch that gets parse_tunnel_config to choke on invalid arguments by returning EINVAL. This will sufficiently solve the problem in the immediate term. In the slightly longer term (e.g. when I get around to it), I'll write a patch which causes vswitchd to reconfigure all ports at startup. Ethan _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
