uniter: bump test timeout

uniter: bump test timeout

fixes lp:1073218; justified in bug comments

https://code.launchpad.net/~fwereade/juju-core/trivial-lp-1073218/+merge/132301

(do not edit description out of merge proposal)

[fwereade, 2012-10-31 11:23:58]

Please take a look.

[jameinel, 2012-10-31 15:00:19]

It makes me wonder if we would be better off with more of an interlock during
the startup rather than just a sleep timeout. However, since this only makes the
test fail rather than potentially hang forever, it seems ok to me.

5.0 seems like a reasonable safety margin to me.

LGTM

[niemeyer, 2012-11-01 14:34:16]

https://codereview.appspot.com/6819058/diff/1/worker/uniter/uniter_test.go
File worker/uniter/uniter_test.go (right):

https://codereview.appspot.com/6819058/diff/1/worker/uniter/uniter_test.go#ne...
worker/uniter/uniter_test.go:786: for {
Isn't this missing a StartSync() here?

[fwereade, 2012-11-07 08:09:05]

https://codereview.appspot.com/6819058/diff/1/worker/uniter/uniter_test.go
File worker/uniter/uniter_test.go (right):

https://codereview.appspot.com/6819058/diff/1/worker/uniter/uniter_test.go#ne...
worker/uniter/uniter_test.go:786: for {
On 2012/11/01 14:34:16, niemeyer wrote:
> Isn't this missing a StartSync() here?

No, because we're not watching anything... but, actually, yes, because we should
really be watching the unit instead of just polling. (This test was written
without a UnitWatcher in its current form - no obstacles to fixing it now.)

[fwereade, 2012-11-20 07:17:56]

On 2012/11/07 08:09:05, fwereade wrote:
> https://codereview.appspot.com/6819058/diff/1/worker/uniter/uniter_test.go
> File worker/uniter/uniter_test.go (right):
> 
>
https://codereview.appspot.com/6819058/diff/1/worker/uniter/uniter_test.go#ne...
> worker/uniter/uniter_test.go:786: for {
> On 2012/11/01 14:34:16, niemeyer wrote:
> > Isn't this missing a StartSync() here?
> 
> No, because we're not watching anything... but, actually, yes, because we
should
> really be watching the unit instead of just polling. (This test was written
> without a UnitWatcher in its current form - no obstacles to fixing it now.)

Actually, on deeper thought, there isn't really any benefit to watching: doing
so *introduces* the requirement to spam StartSyncs (to ensure the watch actually
fires once the uniter has written the address) and is strictly more complex than
just spamming Refreshes until we get what we need.

(To reanswer the previous question: no, we don't need to sync at all, because
none of the code that runs before we set the public address depends on any
watches.)

[fwereade, 2012-12-12 15:44:43]

Please take a look.

[niemeyer, 2012-12-12 16:40:47]

LGTM

[fwereade, 2012-12-14 12:34:38]

*** Submitted:

uniter: bump test timeout

fixes lp:1073218; justified in bug comments

R=
CC=
https://codereview.appspot.com/6819058