charm audit summary

[William Reade]

On Tue, 2012-10-16 at 09:53 -0300, Gustavo Niemeyer wrote:
> 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.

SGTM.

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

Good point.

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

I'm not sure it helps us here -- we can certainly use relation settings
to nudge the unit on the other side into doing something, and that's
absolutely how *charms* should be communicating amongst themselves --
but I am concerned about one charm touching files related to its service
at the same time as another charm does. Maybe this is just bad hygiene
on the charm's part, but I'm not sure -- if the subordinate acts only by
telling the principal to do things, ISTM that that functionality may as
well be entirely within the principal.

So I'm not really concerned about the order in which things run: it's
just about preventing charms from getting into stupid error states
because they weren't able to tweak a local config file because another
hook was doing so simultaneously. Is this scenario crazy?

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

Same unit agent, not same uniter, although I suspect that was just a
thinko. I'm not 100% sure it's a good idea either... but I am really
worried that we're going to end up having to special-case a whole bunch
of unpredictable stuff other than apt.

I agree that stability would need to be considered carefully, but I
don't think security's a concern here: when everything's root within the
container boundary, I don't think that process boundaries buy us much.
And I don't forsee unhelpful behaviour changes... but I am very probably
missing something :).

Cheers
William