charm audit summary

[David Cheney]

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


+1 on a current symlink, even without the rest of your suggestion, this would make it easier to maintain legacy paths, like /usr/bin/open-port

± 1 on one container agent per machine, if only because it blurs the demarcation line between itself and the machine agent.
  
>  
> > The rest of the failures were traced to bug #1067217, whereby non subordinate service units are being allocated on the same machine and thus race for the apt lock.
>  
>  
> With subordinates, this will remain a problem; please consider the
> suggestion above with this in mind.
>  
> > 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!
>  
> Cheers
> William
>  
>  
> --  
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com (mailto:Juju-dev at lists.ubuntu.com)
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev