[ovs-dev] [PATCH] ovs-test: A new tool that allows to diagnose connectivity and performance issues

Ben Pfaff blp at nicira.com
Fri Nov 11 23:42:35 UTC 2011


On Thu, Nov 10, 2011 at 05:26:17PM -0800, Ansis Atteka wrote:
> On Tue, Nov 1, 2011 at 11:18 AM, Ben Pfaff <blp at nicira.com> wrote:
> 
> > On Mon, Oct 31, 2011 at 04:38:51PM -0700, Ansis Atteka wrote:
> > > This tool will be a replacement for the current ovs-vlan-test
> > > utility. Besides from connectivity issues it will also be able
> > > to detect performance related issues in Open vSwitch setups.
> > > Currently it uses UDP and TCP protocols for stressing.
> > >
> > > Issue #6976
>
> > The python/ovstest hierarchy duplicates a bit of the content
> > (dirs.py) and Makefile mechanisms from python/ovs.  Is there a good
> > reason for that?  I wonder why it can't just go in, say,
> > python/ovs/test and reuse the same infrastructure?
> >
> Fixed, but slightly different than you suggested.
> 
> If I would move contents of python/ovstest directory under python/ovs/test
> then both of these Python modules (ovs and ovs.test) would have
> child-parent relations (hence ovs/test would be distributed also with
> python-openvswitch debian package). Unless there is a way I could
> explicitly exclude ovs/test subdirectory from python-openvswitch.install
> file.
> 
> I moved the automake.mk file one level up to include both directories -
> ovstest and ovs - to reflect their sibling relations and share the same
> automake.mk file. Are you ok with this?

OK, that's fine.

> > The string .format method is new in Python 2.6, so we'll need to
> > change it to % or something else to get this to work on XenServers or
> > RHEL5, which have Python 2.4.
> >
> Not Fixed Yet. Can we postpone this till we actually put any effort to
> support ovs-test on XenServer? I can do this once I will have XenServer in
> my testbed.

OK, that's fine.  The problem is not going to be subtle, so there's no
reason to fix it right now.

> > I'm not sure why the variable names in the __main__ block at the end
> > are in all-caps.
> 
> Pylint suggested to use all caps: ID:C0103  Invalid name "node1" (should
> match (([A-Z_][A-Z0-9_]*)|(__.*__))$) Let me know if you still think that
> using lower case would be more appropriate here (*see also Global/Class
> Constants in *http://code.google.com/p/soc/wiki/PythonStyleGuide#Naming)?

I don't understand how these are global or class constants.  They are
assigned values computed at runtime that vary from one run to another.
Perhaps pylint could be placated (if one cares) by moving everything
in the "try" block into a function.



More information about the dev mailing list