charm audit summary

[Gustavo Niemeyer]

On Tue, Oct 16, 2012 at 5:15 AM, William Reade
<william.reade at canonical.com> wrote:
>> 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

Agreed, and there shouldn't be IMO. Charms shouldn't hardcode paths to
the juju tools.

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

That's an interesting case, because apt locking can affect the unit
even when it's not another hook that is running at the same time. This
seems like a good problem to brainstorm on and solve irrespective of
what we do about the hooks specifically, because it's a trivial
operation that people will expect to just work, and it should.

In less trivial cases, relations may also be used to create the
sequencing between the units, when that's really necessary.

> 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

While there would certainly be some value in lock-stepping the
independent uniters, I also see some significant value in the
isolation of units. Stability, security, behavior.. quite a lot will
be unified if we put the units together under the same uniter, and
what today is "just two units in the same container" will become a lot
more involved. We can definitely brainstorm further on the idea, but
it's not a change that seems like a clear win to me, at least.

>> 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!

Indeed! Great work David.


gustavo @ http://niemeyer.net