On Wed, Oct 19, 2016 at 10:42 AM Nate Finch <nate.fi...@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.terr...@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@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
