> On Fri, Sep 19, 2014 at 12:24:38AM +0900, YAMAMOTO Takashi wrote: >> It seems that the behaviour is not so intuitive. >> cf. https://bugs.launchpad.net/neutron/+bug/1346861 >> >> Signed-off-by: YAMAMOTO Takashi <yamam...@valinux.co.jp> > > I am not sure that I understand the bug report there. It might be > reporting an actual bug in OVS. > > The goal of ovs-vswitchd regarding the database is to make sure that > the state of the system is kept up-to-date with whatever is in the > database. Maybe that bug report is saying, "If I have a port, and > then I del-port/add-port that in a single transaction, ovs-vswitchd > does not actually delete a port and then readd it at the datapath > level." If it is saying that, then it is correct. But that could > also happen if you use multiple transactions, because when it is busy > ovs-vswitchd might "miss" some of the intermediate transactions and > just implement the overall effect.
i referred the bug report because it seems that the author of original code mentioned in the bug expected it triggers re-creation of the port. > > The reason that two ovs-vsctl calls always deletes and readds a port > is a little different: the first ovs-vsctl waits for its transaction > to take effect before executing. If you use "--no-wait", then you > just have two bare transactions and won't get the behavior of a > del-port followed by an add-port 100% of the time. yes, it's my understanding. how about the following? YAMAMOTO Takashi Q: It seems that Open vSwitch does nothing when I removed a port and then immediately put it back. For example, consider that p1 is a port of type=internal: ovs-vsctl del-port br0 p1 -- \ add-port br0 p1 -- \ set interface p1 type=internal A: It's an expected behaviour. If del-port and add-port happen in a single OVSDB transaction as your example, Open vSwitch always "skips" the intermediate steps. Even if they are done in a multiple transactions, it's still allowed for Open vSwitch to skip the intermediate steps and just implement the overall effect. In both cases, your example would be turned into a no-op. If you want to make Open vSwitch actually destroy and then re-create the port for some side effects like resetting kernel setting for the corresponding interface, you need to separate operations into multiple OVSDB transactions and ensure that at least the first one does not have --no-wait. In the following example, the first ovs-vsctl will block until Open vSwitch reloads the new configuration and removes the port: ovs-vsctl del-port br0 p1 ovs-vsctl add-port br0 p1 -- \ set interface p1 type=internal _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev