[ovs-dev] [PATCH] ovs-vsctl: Check "ofport" column after adding a new port

Thomas Graf tgraf at redhat.com
Tue Dec 18 00:27:53 UTC 2012


On 12/17/2012 09:44 PM, Ben Pfaff wrote:
> I don't think this is general enough.  It only checks a single port in
> one run, but ovs-vsctl supports an arbitrary number of commands.
> It also should check for the new port using the UUID reported by the
> database server, rather than by name.  I'd also want it to properly
> handle cases like:
>
> 	ovs-vsctl -- add-port br0 eth0 -- del-port eth0
>
> that is, without giving an error.

> It is also possible to expand this, without much extra effort, from
> just adding port to also adding bridges, since one can check that the
> bridge port comes up properly.

I agree with all of your comments but before I continue this exercise:
How do you intend to solve the problem for all cases unrelated to adding
ports and bridges? Do you intend to add status columns for each
changeable table and keep a journal of requested changes with row uuid
and information on how to check for an error condition?

And what about:

  ovs-vsctl -- set Port eth0 a=b -- set Port eth1 c=d

where a=b causes an error and c=d would be successful. Where and how
would you store that error condition?

I still believe that a central stack of errors and warnings as 
implemented by the console proposed is the right way to go. You never
brought up arguments against it that would not also apply to the ofport
approach whereas the central error state storage has the advantage of
solving the error reporting problem for all existing and all future
commands. It also covers the add-port -- del-port case because it
always only cares about the final config state after a chain of
commands have been executed.

There is really not that much of a difference between using ofport or
an equivalent therefore and using an error console with an error
counter except that while your approach misses some cases, the console
will never miss an error. The fact that it may report errors caused by
other clients is true but that also applies to your approach if another
client touches the same row.



More information about the dev mailing list