What are the best practices for stop hook handling?
rye.terrell at canonical.com
Thu Oct 20 14:09:54 UTC 2016
> Subordinate charms only make sense when collocated. And I would argue that
subordinates are extremely common, at least in production environments.
> In this context clean up is very important because it's not unusual for operators
to switch technologies. For example replace telegraf with node-exporter or
With that in mind, I'd like to reiterate one of my original questions: how
do we handle cleanup in the case where two or more colocated charms have
the same dependencies? In the case of background services, do we not stop &
disable them? Do we stop & disable them and expect the remaining charms to
repair the situation?
On Thu, Oct 20, 2016 at 3:32 AM, Jacek Nykis <jacek.nykis at canonical.com>
> On 19/10/16 16:15, Marco Ceppi wrote:
> >> 2. Don't colocate units if at all possible. In separate containers on
> >> same machine, sure. But there's absolutely no guarantee that colocated
> >> units won't conflict with each other. What you're asking about is the
> >> problem colocation causes. If both units try to take over the same
> port, or
> >> a common service, or write to the same file on disk, etc... the results
> >> will very likely be bad. Stop hooks should clean up everything they
> >> started. Yes, this may break other units that are colocated, but the
> >> alternative is leaving machines in a bad state when they're not
> > Colocation is a rare scenario, a more common one is manual provider.
> Subordinate charms only make sense when collocated. And I would argue
> that subordinates are extremely common, at least in production
> In any production deployment I expect some form of monitoring (nrpe,
> telegraf). Many deployments will also use logstash-forwarder,
> landscape-client, ntp, container-log-archive and other subordinate charms.
> So you are looking at 3-4 or more services on each juju machine,
> including LXC/LXD guests and manually provisioned systems.
> In this context clean up is very important because it's not unusual for
> operators to switch technologies. For example replace telegraf with
> node-exporter or collectd.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Juju