[ovs-dev] [PATCH] ovs-test: Enhancments to the ovs-test tool

Ben Pfaff blp at nicira.com
Wed Apr 4 19:53:32 UTC 2012


On Wed, Apr 04, 2012 at 12:47:29PM -0700, Ansis Atteka wrote:
> On Mon, Apr 2, 2012 at 1:28 PM, Ben Pfaff <blp at nicira.com> wrote:
> > Is the special case for 127.0.0.1 useful?  (Why would I want to run
> > this test against localhost?)
> >
> "127.0.0.1 case" allows you to type 2 commands:
> 
> Node1:ovs-test -s 15531
> > Node2:ovs-test -c 127.0.0.1,1.1.1.1 192.<Node1>,1.1.1.2 -d -l 125 -t gre
> >
> 
> instead of 3 commands:
> 
> Node1:ovs-test -s 15531
> > Node2:ovs-test -s 15531
> > Node2:ovs-test -c <Node2>,1.1.1.1 <Node1>,1.1.1.2 -d -l 125 -t gre

Ah, I see.  Thanks, that makes sense.  (I should have read the commit
message more carefully.)

> > xmlrpc_create_test_bridge(): I don't understand in what sense this
> > function is atomic.
> 
> Maybe "atomic" meaning is not appropriate here. With "atomic" I
> meant that we must do everything in one shot. Otherwise, If we would do
> multiple RPC calls just to create the Physical bridge (e.g. 1. creating
> bridge; 2. attaching physical interface to it; 3. moving IP config), then
> after step #2 the ovs-test client wouldn't be able to connect to ovs-test
> server anymore.

OK.  Maybe slightly changing the wording, to avoid "atomic", would
help.

> > But it also seems like it should un-assign the IP
> > address from the original interface.
> >
> I though about the same thing, but this "lazy way" of not unassigning
> the IP address from the physical interface seemed to always work fine.

I've seen this work OK too, but I am not sure whether it is just a
matter of luck.  It could also be that the behavior is kernel version
or driver dependent, so depending on this behavior makes me nervous,

> But I do have to agree with you that this does not look nice, so I will
> try to fix it.

Thanks.

> Ok, to everything else and I will resubmit the patch. Sorry that this time
> I did not create multiple logical patches to make the review easier.

I think it's OK.

Thanks,

Ben.



More information about the dev mailing list