Triggering Server Restarts

[Andrew Wilkins]

On Fri, Aug 22, 2014 at 11:57 AM, John Meinel <john at arbash-meinel.com>
wrote:

> Horacio had an interesting question on IRC and I wanted to bring it up to
> more people to get input.
>
> Specifically, "juju restore" has some properties that are pretty similar
> to "juju upgrade-juju" in that we really want the API server to restart
> after the action has completed.
>
> In the case of "upgrade-juju" the command only schedules an upgrade, and
> the actual upgrade happens asynchronously. When it completes, the
> worker/Upgrader raises UpgradeReadyError which is special cased at the top
> level Runner to realize this is a "die and restart" sort of error.
>
> I think Horacio is desiging "juju restore" to be a bit more synchronous.
> So rather than have a worker/Restorer running in the background, noticing
> that a restore needs to be done and triggering it, he has the API call
> itself do the work.
> I think this is sensible for restore as it has been written.
>
> I think the problem is that to trigger a restart, the worker itself (in
> this case APIServer) should be raising the error, which isn't really
> accessible in the context of the API call. (you want the API call to return
> successfully, an 'error' in this context is handed to the user, not up the
> Worker stack.) And the state/apiserver/client.Client object just has a
> direct reference to State, it doesn't have a reference to
> state/apiserver.Server to be able to trigger that sort of error in the
> apiserver.Server.tomb object.
>

Is there something wrong with giving Client a reference to the tomb? It
needs *something*, so I don't see why not that, which would be the least
amount of work.


> One possibility might be to have a worker/Restarter that watches for
> something (listens on a channel, something), and then triggers an exit with
> an error like UpgradeReadyError.
>
> My personal thought on how "juju restore" should work, is that it wouldn't
> actually be an API call, but instead of doing all the steps of "juju
> bootstrap" it would do all of them except the final "jujud
> bootstrap-state", and substitute in a "jujud restore-state".
> So we would still have everything running the restoration from server-side
> code, but we would be triggering it before we have "created a running state
> server".
> This would have been more of a problem when we were triggering "jujud
> bootstrap-state" from cloud-init, but I'm pretty sure we are just directly
> sshing in and doing the work ourselves now.
>
> I guess it depends if this is an API we *ever* want to trigger at any
> other time than just at the beginning. Maybe we want to have the API so you
> call "rollback" even if it has been running for a while?
>
> John
> =:->
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140822/66e7138b/attachment.html>