Implement system reboot via juju hooks

William Reade william.reade at canonical.com
Mon Aug 11 14:14:24 UTC 2014


On Mon, Aug 11, 2014 at 3:00 PM, Stuart Bishop <stuart.bishop at canonical.com>
wrote:

> On 11 August 2014 18:20, William Reade <william.reade at canonical.com>
> wrote:
>
> > I'd like to explore your use cases a bit more to see if we can find a
> clean
> > solution to your problems that doesn't go too far down the (2) road that
> I'm
> > nervous about. (The try-again-later mechanism is much smaller and cleaner
> > and I think we can accommodate that one pretty easily, fwiw -- but what
> are
> > the other problems you want to solve?)
>
> Memory related settings in PostgreSQL will only take effect when the
> database is bounced. I need to avoid bouncing the primary database:
>  1) when backups are in progress.
>  2) when a hot standby unit is being rebuilt from the primary.
>
> Being able to have a hook abort and be retried later would let me
> avoid blocking.
>

Hmm. The trouble here is that releasing the execution lock would *also*
free up the machine agent to be rebooted -- the benefits of being able to
run other hooks while you wait don't feel quite so compelling to me now.

A locking service would be useful too for units to signal certain
> operations (with locks automatically released when the hooks that took
> them exit). The in-progress update to the Cassandra charm has
> convoluted logic in its peer relation hooks to do rolling restarts of
> all the nodes, and I imagine MongoDB, Swift and many others have the
> same issue to solve.
>

I see -- to get rolling restarts you'd need to spread an awful lot of
finicky logic across the peer relation hooks. I'm expecting to address this
issue by allowing leaders to run actions on their minions. ie as leader,
you can just run the action and wait for it to succeed or fail before
continuing, all inside a single hook. Sane/helpful?

Cheers
William



>
> --
> Stuart Bishop <stuart.bishop at canonical.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140811/e16b4fc5/attachment.html>


More information about the Juju-dev mailing list