lp://staging/~axwalk/juju-core/lp1211147-no-log-forwarding-on-state

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

1629. By Andrew Wilkins on 2013-08-14

Don't forward logs if deploying on state server

Previously, whenever a unit was deployed a configuration
file was created in /etc/rsyslog.d to forward logs to
the state servers. This introduced a feedback loop when
the the unit was deployed on a state server machine.

Now, check for the existence of /etc/rsyslog.d/25-juju.conf
before creating an additional configuration.

Fixes bug #1211147

1628. By Jeroen T. Vermeulen on 2013-08-09

[r=jtv] Modernize gocheck import in a test.

1627. By Andrew Wilkins on 2013-08-09

[r=axwalk] worker/uniter: use loggo

As requested in review of bug 1027876.

https://codereview.appspot.com/12452043/

1626. By Roger Peppe on 2013-08-08

[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.

https://codereview.appspot.com/12354043/

1625. By Roger Peppe on 2013-08-08

[r=rogpeppe] state: hopefully make tests more reliable

We had a sporadic test failure in MachineSuite.TestWatchMachine:
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 passes

scenario 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 fails

The 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.TestWatchMachine 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.

https://codereview.appspot.com/12352044/

1624. By Roger Peppe on 2013-08-08

[r=rogpeppe] state/testing: use reflect.Select

Use go1.1 features, as suggested by TODO comment.

https://codereview.appspot.com/12452045/

1623. By Martin Packman on 2013-08-08

[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 on 2013-08-08

[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.

https://codereview.appspot.com/12667043/

1621. By Sidnei da Silva on 2013-08-08

[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

1620. By Dimiter Naydenov on 2013-08-08

[r=dimitern] state/api: Uniter client-side API

This introduces part of the client-side API
needed by the uniter worker. There will be
a lot more calls in there, but they will be
added incrementally.

https://codereview.appspot.com/12661043/

R=gz, rogpeppe