On 12/04/2012 08:25 PM, Ben Pfaff wrote:
It tells a human user that the operation failed. It could also notify
a script that the operation failed, e.g. if we decided to return a
nonzero exit status. (ovs-vsctl is intended for use by both humans
and programs.)
I'm perfectly willing to add another column, or use another existing
column, to provide more detail about why a particular port or
interface cannot be added.
I'm not against that at all. I will be glad to come up with a patch that
does just that and allow to exit ovs-vsctl with a proper exit code in
case add-port fails. OTOH, I doubt that it will be possible to implement
this for all error scenarios that may occur while a bridge reconfigures.
The "ofport" column reports the OpenFlow port number used by a
particular interface, which is part of the state of the OpenFlow
switch.
True but you have to admit that it follows the request/reply schema
that you bring up as a no-go in the context of my proposal.
It would contain that, but it might also contain essentially unrelated
information that just happens to be logged during switch
reconfiguration, which in some cases can take several trips through
ovs-vswitch'd main loop.
That's not a problem in my eyes. More on that later on in my reply.
Using a "console" doesn't actually tell you directly whether the
operation you executed succeeded or failed. You may be able to figure
that out as a human by carefully reading the output. But there's
likely to be a lot of irrelevant spew, especially in a large system
with thousands of interfaces.
If there is irrelevant spew then we may have to reconsider some log
messages because the very same messages will go to the log file and
that log file is currently the only way to figure out whether a bridge
has been brought up successfully.
So if you claim that it's impracticable or even impossible to verify
the success or status of a reload with my model then any such claim
would also apply to the current use case of looking at the logfile.
This is also a rather unconventional design. Can you point me to
other systems that print a complete dump of their log messages to the
console, regardless of relevance, after a single operation? I would
like to read up on user feedback to such designs, or rely on my own
experience if I happen to already use such a system without realizing
it.
It's not _that_ unconventional. If you configure a hardware switch,
modify the configuration and do a reload you will also get errors and
informational messages printed to the console. So the concept itself
is not new in that regard.
What makes it unconventional is the 1:n nature of ovs-vsctl and the fact
that ovs-vsctl reloads after each command. If you step back a bit and
look at what ovs-vsctl actually does in the background you will agree
it's something like this:
MODIFY-DB;
COMMIT;
RECONFIGURE-ALL-BRIDGES;
[WAIT-FOR-RELOAD-TO_COMPLETE];
My opinion is that if the user requests to wait for the reload to
complete that implicitly means that the user is expecting functional
bridges after the completion of ovs-vsctl.
It seems natural to me that if something is not as expected by the
user, ovs-vsctl should notify the user as directly as possible and that
includes spewing out errors and warnings that prevented the bridge
from configuring itself correctly.
I guess you would agree that if ovs-vsctl would offer a command like
"reconfigure" to explicitly reconfigure all bridges then it would be
very desirable to print out all errors that occurred while bringing
up the bridges (again).
I'm not claiming that the patches are perfect at this stage, we may
want to limit the output to warnings and errors and omit informational
messages and we may want to add a parameter to enable quiet mode for
scripts. And we definitely want to be able to return success/error in
a true/false manner for scripts wherever possible but as you said, the
database model is not request/reply friendly and we will not be able
to handle all errors that could possibly occur with the "ofport"
approach.
Would the patch become more acceptable with a (-q) quiet command line
option for scripts and if only warnings and errors were printed by
default?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
