On 11/29/2012 06:23 PM, Ben Pfaff wrote:
It's better in that it would simply report whether the port was successfully added in an unambiguous fashion, instead of shipping possibly a lot of possibly irrelevant log data to the user, often regardless of whether the port was added successfully or not. Your own example shows this.
It would basically allow to print "Error: Unable to add port foo to bridge bar" which is not really helpful.
Also, the database is designed to maintain state. This patch series instead tries to use it in a request/reply manner. That works OK with a single client but it's going to fall down whenever there's more than one client making requests in parallel.
Not sure why reading the "ofport" column would not be request/reply manner. Despite of that, I _do_ consider the "console" content as state. It always reflects the current side effects, exceptions and informational messages based on the current active configuration. As proposed, ovs-vsctl would always display the most current state of the console. This means that it may include a message that has not been caused by the specific ovs-vsctl but it would still be relevant as you most likely want to do something about it. If this is not desirable, I would be happy to filter out any messages that have not been logged for the configuration sequence number in question. I'm already encoding cur_cfg in all log messages for that purpose. I just figured that as an administrator you always want to be made aware of when a reconfigure spits out errors _after_ your command has been processed. I'm much more interested in the state that will be used than getting feedback about any intermediate state that was immediately overwritten again. I am open to modifying this further by f.e. * adding a switch to enable/disable the console * limiting messages to >= WARN or make this configurable (I personally find all INFO messages useful) Pros over reading the "ofport" column: * I get notified when another ovs-vsctl user interferes that causes errors or warnings that I may not expect. * The proposed console works for all commands, across all modules in vswitchd. As you stated correctly, the design does not really allow for a request/reply protocol to solve this on a high level. * Platform specific layers can define error messages and be verbose about errors and thus increase usability. * ovs-vsctl show-console gives you quick, neat overview of the current state of your bridges without having to check the logfile and parsing that in your brain. Cons: * Probably need to improve some of the log messages a bit to make it clearer to the user what is meant exactly. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
