charm audit summary

[William Reade]

On Tue, 2012-10-16 at 12:16 -0300, Gustavo Niemeyer wrote:
> On Tue, Oct 16, 2012 at 10:48 AM, William Reade
> <william.reade at canonical.com> wrote:
> >> 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.
> 
> I feel the opposite: imagine you have an haproxy charm and
> haproxy-conf subordinates. It feels quite elegant to send
> configuration snippets for specific services to the principal, while
> it would be very messy to have everyone playing around with the
> configuration files directly at their will, no matter whether hooks
> are running serially or not.

Fair enough, that is indeed nice -- but in principle, AIUI, the
principal is not required to know anything about the subordinate, and
the sort of mechanism you describe assumes a principal which does.

> > 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?
> 
> It's not crazy, but it's strongly discouraged. Nothing on earth will
> help us getting different people to mechanically sort out conflicts
> changing the same files in a smooth and correct way across the board.
> We need charms with proper interfaces in those cases.

Fair enough -- we should probably try to make a point about being
explicit about that somewhere, so that if people *do* need to do this
sort of thing the will know they need to take extra care.

> > 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
> 
> I was talking about that as well. One error on one uniter will restart
> the agent, compromising the security of one uniter compromises them
> all, etc.

We would indeed need to change things around a little to come up with a
model that worked well... but if it doesn't immediately seem like a good
idea I'm happy to drop it.

Cheers
William