What are the best practices for stop hook handling?

[Marco Ceppi]

On Wed, Oct 19, 2016 at 10:42 AM Nate Finch <nate.finch at canonical.com>
wrote:

> 1. The stop hook happens when the unit is being removed entirely.  It does
> not run on reboot (and there's no reboot hook).  The docs on the start hook
> mention this: "Note that the charm's software should be configured so as to
> persist through reboots without further intervention on juju's part."  The
> stop hook should clean up everything to the best of its ability, to make
> the machine appear as it did before the unit was added to it (so, uninstall
> the software, remove all config files, etc).
>

The impression provided, is that stop isn't a removal of software, but a
halt of the software running. If we intend it to be a removal, we should
name the hook uninstall otherwise start and stop hooks, which are paired by
naming, don't convey accurately what they do.

Furthermore, are you certain that Juju doesn't run a stop hook on
containered workloads when the parent machine gets a `juju-reboot` event?
If it does, then removal of software to perform a reboot isn't really ideal.


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


> 3. Many charms don't do this (in fact, there's an email about this on our
> internal mailing list right now). They absolutely should.   Many charms get
> away with not doing cleanup because Juju's main use case is containers and
> throw-away VMs that are discarded after the unit is removed... but there
> are many cases where this does not happen, such as using the Manual
> provider or colocated units.  Please write cleanup code.
>

I disagree. The entire premise and "guarantee" we've given charmers to date
is you have root on a machine, do what you'd need. Outside of
"hulk-smashing" which we really don't support, and manual provider, you're
given a machine to do what you need to setup. Having to further distill how
to "clean up" seems like a step backwards in what we care about with Juju,
which is the setup and operations of software.

Ultimately, this goes away when we start using snaps in charms, but I would
be hesitant to implement file cleanup now when the future of software
installation is trending towards Snaps.


On Wed, Oct 19, 2016 at 10:17 AM Rye Terrell <rye.terrell at canonical.com>
> wrote:
>
> I have a number of questions regarding how to handle stop hooks properly:
>
> 1. Background services - stop them or stop & disable them?
>
> The docs say "stop runs immediately before the end of the unit's
> destruction sequence. It should be used to ensure that the charm's software
> is not running, and will not start again on reboot."
>
> Can anyone verify that that is correct? If so, it seems clear that
> services should be stopped & disabled, but leaves me with another question
> - is there no hook that handles scenarios like host rebooting?
>
> If it's not correct, what is the proper behavior for the stop hook
> handler? Stop & disable on stop hook and start & enable on start hook?
>
> 2. Background services - how do we handle colocated applications with
> shared background services?
>
> I'm not sure this is something we support, but if so, what do we do when
> one application is stopped and it has a colocated application that shares a
> background service dependency? I don't think this is something we can
> detect at the charm level, so do we _not_ stop services so that we don't
> cause conflicts?
>
> 3. File cleanup - is anyone doing this?
>
> The docs also say "Remove any files/configuration created during the
> service lifecycle" is part of a charm's stop hook handling behavior. My
> experience isn't exactly vast, but I'm unaware of charms doing this. Is
> this something we actually do? Should we keep that statement in the docs?
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20161019/647fad9e/attachment.html>