On Fri, Aug 22, 2014 at 11:57 AM, John Meinel <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
