Comment 3 for bug 1844773

How does the agent who would drive the hook distinguish from "I'm started
because the machine restarted" and "I'm restarted because the agent
restarted" or "I'm restarted because I lost connectivity to the outside
world" or "I restarted because of an unhandled error".

My primary concern is introducing something like this, when we just went to
a lot of effort to *not* trigger config-changed on all of those types of
events. I can see a case for "Start", but we'd want to understand how we
would be giving a reliable signal that isn't just moving it around.

On Mon, Oct 7, 2019 at 6:31 PM Richard Harding <email address hidden>
wrote:

> We talked about this one during the openstack sync call last week. The
> consensus was that the goal was to help tell when a system was coming up
> from a cold boot (e.g. the system was restarted, not the agent or the
> service). The idea is that if the cloud were to shut down it was
> important to know it was coming up from a cold start situation. The
> discussion was to leverage the start hook as a promised "first hook on
> reboot, as long as not in a series-upgrade or other defined situation".
> In this way logic could be handled on the start hook to help manage this
> cold start situation.
>
> We agreed that the openstack team would put together some defined
> scenarios they want to make sure are covered and we'd make sure that
> this start hook on reboot would cover those in a sufficient manner and
> look at adding to the next cycle roadmap.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1844773
>
> Title:
> Need a consistent set of hook events surrounding stop/start of
> application unit (ie. reboots)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1844773/+subscriptions
>