[ovs-dev] [PATCH] ovs-vsctl: check if the device name is valid

Thomas Graf tgraf at suug.ch
Thu Nov 1 17:47:26 UTC 2012


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?



More information about the dev mailing list