Multi hop tests

[rade]

test peer discovery, multi-hop routing and gossip forwarding.

increases code coverage as follows:

$ diff /tmp/coverage-before.txt /tmp/coverage-after.txt 
59c59
< github.com/weaveworks/weave/ipam/allocator.go:454:        actorLoop           90.9%

---
> github.com/weaveworks/weave/ipam/allocator.go:454:        actorLoop           100.0%
86,87c86,87
< github.com/weaveworks/weave/ipam/http.go:14:          badRequest          0.0%
< github.com/weaveworks/weave/ipam/http.go:20:          HandleHTTP          54.5%

---
> github.com/weaveworks/weave/ipam/http.go:14:          badRequest          100.0%
> github.com/weaveworks/weave/ipam/http.go:20:          HandleHTTP          56.8%
340c340
< github.com/weaveworks/weave/router/connection.go:125:     BreakTie            0.0%

---
> github.com/weaveworks/weave/router/connection.go:125:     BreakTie            66.7%
351,352c351,352
< github.com/weaveworks/weave/router/connection.go:279:     run             80.0%
< github.com/weaveworks/weave/router/connection.go:359:     registerRemote          60.0%

---
> github.com/weaveworks/weave/router/connection.go:279:     run             85.0%
> github.com/weaveworks/weave/router/connection.go:359:     registerRemote          80.0%
354c354
< github.com/weaveworks/weave/router/connection.go:391:     actorLoop           62.5%

---
> github.com/weaveworks/weave/router/connection.go:391:     actorLoop           75.0%
372c372
< github.com/weaveworks/weave/router/connection_maker.go:161:   queryLoop           87.5%

---
> github.com/weaveworks/weave/router/connection_maker.go:161:   queryLoop           100.0%
375c375
< github.com/weaveworks/weave/router/connection_maker.go:249:   addPeerTargets          46.2%

---
> github.com/weaveworks/weave/router/connection_maker.go:249:   addPeerTargets          100.0%
450c450
< github.com/weaveworks/weave/router/gossip_channel.go:57:  deliverUnicast          54.5%

---
> github.com/weaveworks/weave/router/gossip_channel.go:57:  deliverUnicast          72.7%
489c489
< github.com/weaveworks/weave/router/local_peer.go:183:     handleAddConnection     50.0%

---
> github.com/weaveworks/weave/router/local_peer.go:183:     handleAddConnection     61.5%
526c526
< github.com/weaveworks/weave/router/peers.go:81:           FetchAndAddRef          0.0%

---
> github.com/weaveworks/weave/router/peers.go:81:           FetchAndAddRef          100.0%
554c554
< github.com/weaveworks/weave/router/router.go:282:     handleUDPPacketFunc     71.9%

---
> github.com/weaveworks/weave/router/router.go:282:     handleUDPPacketFunc     87.5%
583c583
< github.com/weaveworks/weave/router/surrogate_gossiper.go:31:  Gossip              0.0%

---
> github.com/weaveworks/weave/router/surrogate_gossiper.go:31:  Gossip              100.0%
609c609
< total:                                (statements)            82.0%

---
> total:                                (statements)            83.0%

The difference in /ipam/http.go is weird. It is hitting the badRequest(w, fmt.Errorf("Unable to allocate: %s", err)) case in router.Methods("POST").Path("/ip/{id}/{ip}/{prefixlen}"), which isn't exercised by the new test , so it must be something coming from another test.

The increased connection.BreakTie coverage, and related to that the increased local_peer.handleAddConnection coverage, I think is just down to luck, though it is possible that the new test increases the probability of tie breaks occurring.

[tomwilkie]

Hold off on submitting this until ive upped the have quota. Need at least 24 vms (2 concurrent runs x 4 shards x 3 vms).

[rade]

Hold off on submitting this

The tests on the branch have been running just fine.

[tomwilkie]

Have you have two test runs concurrently? I upped the vm quota recently, but I don't remember what to.

[rade]

Have you have two test runs concurrently?

I think so.

[tomwilkie]

Ah okay then fire away.

I would like to enhance the scheduler so we don't have 2 of the 3 vms
sitting idle for the majority of tests that only need 1 vm. At some point
in the future.

On Saturday, 11 July 2015, Matthias Radestock [email protected]
wrote:

Have you have two test runs concurrently?

I think so.

—
Reply to this email directly or view it on GitHub
#1117 (comment).

[tomwilkie]

Quota is 32 cores, so plenty.