charm audit summary

[roger peppe]

On 16 October 2012 09:15, William Reade <william.reade at canonical.com> wrote:
> 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?

I'm -0.5 on running all a container's unit hooks exclusively to one another.
It seems to me that if we do that, one charm hanging up (for example,
a subordinate taking 15 minutes to download a dependency)
can cause all the other charms in the container to cease reacting.
I'm not sure that doing this solves all the concurrency issues,
and I think it might encourage people to write charms in a way
that relies on this behaviour (for example subordinate charms that
delve into the inner workings of other charms) and make things
more fragile in general.

As for running all the uniters for a container in a single process
(to enable a single binary for all units in a container)
I don't mind too much; I can see that this might be useful
because of the backward-compatibility issue, and also
because we will probably want to support running of juju
executables from outside the context of a charm.