lp:~danilo/juju-core/watch-units

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

1323. By Данило Шеган on 2013-06-25

Make NewDeployer accept MachineUnitsWatcher instead of UnitsWatcher as an argument.

1322. By Ian Booth on 2013-06-24

[r=jameinel] Remove Metadata() method from Instance interface

The machine metadata is not aways available, and is only used
when startInstance is called. So have startInstance return the
metadata separately along with the instance.

https://codereview.appspot.com/10384049/

1321. By Frank Mueller on 2013-06-21

[r=themue] ec2: moved the http storage reader and tests

Moved the HTTP based StorageReader and the test server
for it to environs/ec2 and adopted those changes at
the synctools.

https://codereview.appspot.com/10296046/

1320. By Roger Peppe on 2013-06-21

[r=rogpeppe] state/apiserver/machine: add AgentAPI.SetPasswords

We also add the client side, and implement it in such a
way that it can easily be incorporated into the unit agent
API.

https://codereview.appspot.com/10449044/

1319. By William Reade on 2013-06-21

[r=fwereade] state: aggressive removal of pending units

In response to lp:1190715, we make the following changes:

  * service destruction now adds a cleanup doc that churns through all a
   service's units destroying or removing them where possible.
  * unit destruction short-circuiting is now attempted when the unit agent
   has not yet set a status.

...and make the following opportunistic changes for sanity's and clarity's
sakes:

  * clarify and make consistent the similar transaction-building loops
   in service.go and unit.go (in particular, Unit.Remove was noticeably
 simplified).
  * resolve races around unit destruction in which charm changes and
   machine assignment changes are not properly taken into account.

...supported by testing changes as follows:

  * added SetRetryHooks for verifying a commonly-interesting-to-test
   scenario (set up txn; break txn; verify effect of retried txn)
  * SetBeforeHook became SetBeforeHooks, because that happened while I
   was figuring out SetRetryHooks, and I decided it was a nice change.
  * preventUnitDestroyRemove is much simpler and no longer needs the
   state argument; this is annoyingly noisy.
  * assertUnitLife and assertUnitRemoved were taken off UnitSuite and used
   elsewhere.

The macroscopic effect of this is currently limited. Units that are manually
removed will be removed more quickly more often, which is nice; but the big
problem in lp:1190715 is related to service destruction, and that's not
directly helped by this branch.

When we merge a cleanup worker integration branch, though, this bug will be fixed pretty nicely for all environments running this code (on both client and server).

1318. By Roger Peppe on 2013-06-21

[r=rogpeppe] state/api/machineagent: new package

This provides the client side of state/apiserver/machine.AgentAPI.

https://codereview.appspot.com/10437043/

1317. By Roger Peppe on 2013-06-21

[r=rogpeppe] state/api/machiner: rename Machiner to State

As discussed online.
Also make the Machiner entry point consistent with
Client by not returning an error.

https://codereview.appspot.com/10364046/

1316. By Roger Peppe on 2013-06-21

[r=rogpeppe] state/machine: new agent API

As discussed, for testing reasons it makes sense to
place APIs for a given agent alongside one another,
so this CL puts the machiner API and the machine agent
API alongside one another.

Client-side machine agent API in a subsequent CL.

Re-proposing to avoid the prereq, which I can't
submit right now.
Original CL here: https://codereview.appspot.com/10398043/

https://codereview.appspot.com/10384046/

1315. By Jeroen T. Vermeulen on 2013-06-20

[r=jtv] Create temporary cert file for each ManagementAPI.

For now, each high-level function in the Azure provider will create its own storage contexts and management-API objects as needed. In the case of the management API, that comes with a temporary file containing an Azure certificate. (There is another way to pass the certificate to go-curl, but we want to avoid the complications and especially the unknowns at this point).

Once done with your request(s) to the management, you release it. This cleans up the certificate file, but in the future it may also serve as a hook for connection pooling. We'll treat optimization as a separate problem — it seems easy but this sort of thing often brings out creative tendencies that aren't worth the time just at the moment. As long as we don't need any actual cleanup code for the storage-API side, we chose not to create a cleanup method there. This is all internal detail after all; it doesn't affect any exported APIs.

1314. By Jeroen T. Vermeulen on 2013-06-20

[r=jtv] Helper: test a function for correct locking.

This is the outcome of discussion at
https://code.launchpad.net/~jtv/juju-core/create-gwacl-sessions/+merge/170032
but produces a helper that is much, much simpler. It could become generic,
although one thing is still missing: it currently only works for locks that
are of type sync.Mutex. It probably ought to work for any type of lock.

Failure of a function to acquire the right lock(s) is a constant risk in
concurrent programs, so one of the things most worth testing, but it's also
relatively hard to test for and so nobody ever does it. Of course if you
can forget the locking you can also forget the test, but this helper makes it
very easy to guard against regressions.