On 11/01/12 at 09:44am, Ben Pfaff wrote: > ovs-vsctl does not make Netlink calls. It only updates the database, > via ovsdb-server. ovs-vswitchd does make the Netlink calls, but it > doesn't talk directly to ovs-vsctl. It only monitors the database. > > > Currently the logfile has to be consulted after each invocation of > > ovs-vsctl to verify whether there was an error or not. > > > > Would you accept a patch to pipe what goes into the logfile in > > responds to a ovs-* command to stderr as well? > > I can't imagine a clean way to do that. ovs-vswitchd makes the > Netlink call. It doesn't communicate directly with ovs-vsctl. It > does talk to ovsdb-server, which talks to ovs-vsctl. > > Stepping back: I support your basic proposal, that "ovs-vsctl > add-port" should report a problem if the port cannot successfully be > added. The issue is that, so far, the approaches I've seen don't fit > well with the overall Open vSwitch design. Here is another approach > that fits better: make "ovs-vsctl add-port" check the value that > ovs-vswitchd assigns to the "ofport" column in the new Interface > record. When a port is added successfully, this column receives a > positive integer value; when adding a port fails, it receives the > value -1. I'd accept a patch to do this. > > Currently, nothing reports the particular reason why a port cannot be > added, but if this is really necessary (it seems like a fairly minor > refinement) then we could add a column to hold a status string.
Exactly. I am aware of the architectural reasons why the behaviour is as it is now. I haven't looked too deep into the code yet but I realized that if ovs-vsctl is to be the major CLI UI for administrators to use then it needs usability improvements like this. I like your proposal, it is simple yet effective and does not require major surgery. I was considering to add a notification bus allowing for ovs-vsctl to sleep and wait for a success or error notification and thus block until the operation has been carried out by vswitchd or a timeout is reached. It would be more flexible but also more intrusive and complex. I doubt that adding ports is the only operation that is affected by the above usability defect, right? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
