lp://staging/~axwalk/juju-core/lp1211147-deployer-check-isstateserver
- Get this branch:
- bzr branch lp://staging/~axwalk/juju-core/lp1211147-deployer-check-isstateserver
Branch merges
Branch information
Recent revisions
- 1630. By Andrew Wilkins
-
worker/deployer: add flag to control syslog fwd
- Add flag to NewSimpleContext to enable syslog forwarding
- Add util function in api/agent, HasJobs(*Entity, params.MachineJob)
- Update jujud to make use of these - 1626. By Roger Peppe
-
[r=rogpeppe] all: use go1.1 features
Use method expressions where appropriate
and reflect.SliceOf. There are still a couple
more places that could benefit, but they
are slightly larger changes that justify a CL
of their own. - 1625. By Roger Peppe
-
[r=rogpeppe] state: hopefully make tests more reliable
We had a sporadic test failure in MachineSuite.
TestWatchMachin e:
the last AssertOneChange call received an extra event.My analysis of the failure goes something like this.
There are two possible scenarios:scenario 1:
call Machine.Watch
remove machine
StartSync
state/watcher polls, finds that object has disappeared
EntityWatcher asks to watch object
EntityWatcher sends initial value on channel
state/watcher produces no value, because there's no object.
test passesscenario 2:
call Machine.Watch
remove machine
StartSync
EntityWatcher asks to watch object
EntityWatcher sends initial value on channel
state/watcher produces a value for the object
state/watcher polls, finds that object has disappeared
EntityWatcher receives watcher change and sends to Changes
test reads unexpected value
test failsThe problem is that when StartSync returns we have no idea
whether the state/watcher code has started to poll for new
changes or not.By using Sync instead of StartSync, we ensure that at least
the state/watcher code is in a known state before continuing
to assert whether the watchers built on top of it it will or won't
send events.The only reason for StartSync's existence, AFAIR, is to avoid
a possible deadlock situation where the state/watcher code
is trying to send on a watcher channel but the test code is
not ready to receive on that channel.However, in all the places that use NotifyWatcherC and StringsWatcherC,
the state/watcher code is actually sending to a separate goroutine
which is always ready to receive any change. So it's safe
to use Sync rather than StartSync.I do not understand the "hence cannot verify real-world coalescence behaviour"
comment in the NewLax* functions. If there is coalescence to be verified,
using StartSync rather than Sync is a poor way of verifying it, as
the only allowance that StartSync makes is a few nanoseconds and one or two context
switches - that's not much opportunity for coalescence to happen,
and all tests pass with this CL, which leads me to suspect smoke
and mirrors.If anyone sees a MachineSuite.
TestWatchMachin e sporadic failure
with this CL applied, I'd very much like to know, as it means my
analysis is flawed :-).FWIW, another possibility would be to make StartSync return when
it's certain that the watcher will start a poll before doing anything else.
This would involve a certain amount of restructuring of the
state/watcher code. - 1624. By Roger Peppe
-
[r=rogpeppe] state/testing: use reflect.Select
Use go1.1 features, as suggested by TODO comment.
- 1623. By Martin Packman
-
[r=gz] state: Use machine addresses from unit
Make Unit.PublicAddress check for addresses an associated machine
by preference and select an appropriate one. This is the first
step towards removing PublicAddress and PrivateAddress from unit.https:/
/codereview. appspot. com/12218043/ R=dimitern, wallyworld
- 1622. By Michael Nelson
-
[r=dimitern],[bug=1028053] Clarify error message for status with no env.
This doesn't change the functionality, but just prepends to the error
message returned when 'juju status' is unable to connect to the
environment.Initially I wanted to add a custom error for authorisation so that
I could assume that !AuthorisationError means that the environment
isn't bootstrapped, but there are obviously loads of other reasons
why juju would be unable to connect to the environment.Another option would be to specifically identify the error within
each provider that means that the environment hasn't been bootstrapped
and display "Environment not bootstrapped" only in those cases. - 1621. By Sidnei da Silva
-
[r=sidnei],[bug=1210086] Fallback cost sort to mem, cpu-power, cpu-cores
Not all environments provide a cost option, so when computing an appropriate
instance type from provided constraints, use mem, cpu-power and cpu-cores as
fallback options. When any two of them are the same, we fallback to the next
option.https:/
/codereview. appspot. com/12569044/ R=dimitern, rogpeppe
Branch metadata
- Branch format:
- Branch format 7
- Repository format:
- Bazaar repository format 2a (needs bzr 1.16 or later)
- Stacked on:
- lp://staging/~go-bot/juju-core/trunk