Cannot use juju-reboot as a part of a `juju run` invocation

[Dmitrii Shcherbakov]

Some context:

https://bugs.launchpad.net/juju/+bug/1989629
https://github.com/openstack-charmers/zaza-openstack-tests/issues/921

Use-case: we would like to reboot units in a juju-controlled manner (to avoid doing a reboot amid a hook execution) within functional tests. Using `juju run -u <unit> juju-reboot --now` seems like a natural candidate but this is not allowed by Juju since it treats `juju run` invocations as unnamed actions:

juju run --unit ovn-dedicated-chassis/0 'juju-reboot --now' ; echo $?
ERROR juju-reboot is not supported when running an action.
1

Likewise, I cannot invoke `juju-run` with a unit context from a `juju run` invocation (presumably because that would be mixing the unnamed action context and the context requested for juju-run):

$ juju run --unit ovn-dedicated-chassis/0 'juju-run' ; echo $?
ERROR cannot use "juju-run" as an action command (not supported)
1

It is possible to do something like this:

juju ssh ovn-dedicated-chassis/0 'sudo juju-run -u ovn-dedicated-chassis/0 "juju-reboot --now"' ; echo $?
Connection to 10.10.20.40 closed.
0

$ juju show-status-log ovn-dedicated-chassis/0
Time Type Status Message
# ...
19 Sep 2022 15:01:59+03:00 workload active Unit is ready
19 Sep 2022 15:02:19+03:00 juju-unit executing running action juju-run
19 Sep 2022 15:02:19+03:00 juju-unit idle
19 Sep 2022 15:05:02+03:00 juju-unit executing running commands
19 Sep 2022 15:05:02+03:00 juju-unit rebooting
19 Sep 2022 15:06:22+03:00 juju-unit executing running start hook
19 Sep 2022 15:06:25+03:00 workload active Unit is ready
19 Sep 2022 15:06:25+03:00 juju-unit idle

Except it does not provide a good feedback loop on the completion of a reboot. We can monitor juju status and act accordingly until the unit becomes active again but having a native way to do it seems like a better idea.

[John A Meinel (jameinel)]

I don't have a problem with juju-reboot being available from an action
context. We'd have to think about when does the "action" complete? Is it
completed and then a reboot triggers, or is the action still pending during
the reboot. What is the entry point when you come back in? If you just
unpowered the machine during an action, I believe we would come back up
trying to run that action again, but you certainly don't want to have an
endless loop of juju-reboot firing, causing the action to restart, causing
juju-reboot to trigger, etc.

On Tue, Nov 15, 2022 at 4:56 AM Canonical Juju QA Bot <
<email address hidden>> wrote:

> ** Changed in: juju
> Milestone: 3.0.1 => 3.0.2
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1990140
>
> Title:
> Cannot use juju-reboot as a part of a `juju run` invocation
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1990140/+subscriptions
>
>

[Dmitrii Shcherbakov (dmitriis)]

Agreed, it does seem like there are scenarios where an action could
have pre-reboot and post-reboot logic.

This LP wasn't created in relation to the series upgrade use-case,
however, it does remind me of the pre-series-upgrade and
post-series-upgrade workflow for which there are two separate events.

https://juju.is/docs/olm/manage-machines#heading--upgrade-the-ubuntu-series-of-a-machine
https://juju.is/docs/sdk/pre-series-upgrade-event
https://juju.is/docs/sdk/post-series-upgrade-event

From the operations point of view, there are trade-offs as to whether
to treat what happens before a reboot and after a reboot as a single
event or not (or a single action). We could have charm authors
implement two kinds of events for pre- and post- processing
(potentially extending the framework to provide default handler names
for that too) or provide them with some indicator on whether a reboot
happened since the last invocation of an action or not so that they
can make the necessary multiplexing.

I'm wondering how complicated would it be for Juju to have a slightly
different hook context for the post-reboot event to allow for
multiplexing in the framework (e.g. storing a sequence number to
account for one or multiple reboots) and treat an action as completed
successfully so long as both the pre-reboot and all post-reboot
executions succeed.

On Wed, Nov 16, 2022 at 7:57 PM John A Meinel
<email address hidden> wrote:
>
> I don't have a problem with juju-reboot being available from an action
> context. We'd have to think about when does the "action" complete? Is it
> completed and then a reboot triggers, or is the action still pending during
> the reboot. What is the entry point when you come back in? If you just
> unpowered the machine during an action, I believe we would come back up
> trying to run that action again, but you certainly don't want to have an
> endless loop of juju-reboot firing, causing the action to restart, causing
> juju-reboot to trigger, etc.
>