What are the best practices for stop hook handling?

Rye Terrell 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
collectd.

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>
wrote:

> On 19/10/16 16:15, Marco Ceppi wrote:
> >> 2. Don't colocate units if at all possible.  In separate containers on
> the
> >> 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
> very
> >> 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
> colocated.
> >>
> >
> > 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
> environments.
>
> 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.
>
> Regards,
> Jacek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20161020/6cd95c84/attachment.html>


More information about the Juju mailing list