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. 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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
