charm audit summary

[William Reade]

On Tue, 2012-10-16 at 17:38 +1100, David Cheney wrote:
> Of the 28 charms that failed:
> 
> 0 charms failed because of compatibility with the Go Juju hook commands.

Woot!

> 9 charms failed because they hardcode the path to hook commands, mainly open-port. It is not clear if this is a bug in the charms, i.e., do we mandate to charm authors they should not assume a path for the hook commands, or in the Go implementation (we will have to provide compatibility symlinks)

At the moment, there is no guarantee that the right open-port binary for
one unit in a container is the same as the right binary for another
unit; and I don't believe that we could have (easily) fixed the python
to both make that guarantee and implement tool upgrades. But, without
upgrades existing, I guess people have become used to the single
open-port binary being in a predictable location.

Relatedly: something I think Clint said the other day -- that
subordinates often don't play well when they're running hooks at the
same time (apt locking in particular, but I think that's just one
symptom of a fundamental issue) -- has been making me think.

What's the immediate crack-test reaction to the idea that the "unit"
agent should actually be a "container" agent, which runs the Uniters for
every unit in that container? It would demand some implementation tweaks
to allow us to start/stop uniters independently, but it would make it
much easier to have (effectively) a global hook lock... and it kinda
feels like the effectively lockstep upgrading of unit tools would be
neater than the current model, and would mean that all we ever needed in
any container or machine was a tools dir containing real version subdirs
and a single "current" symlink. And *then* we could have compatibility
symlinks without any trouble. Thoughts, anyone?

> The rest of the failures were traced to bug #1067217, whereby non subordinate service units are being allocated on the same machine and thus race for the apt lock.

With subordinates, this will remain a problem; please consider the
suggestion above with this in mind.

> Taking the previous paragraph into consideration, the number of working charms could be more than 70, which I view as a fantastic achievement. 

Woot again!

Cheers
William