charm audit summary

[Kapil Thangavelu]

On Tuesday, October 16, 2012, Gustavo Niemeyer wrote:

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


Even in pyjuju those paths aren't stable depending on origin they may be
usr/local

I'd consider them charms bugs.


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

Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20121016/ec2ba9ba/attachment-0001.html>