On Fri, Aug 22, 2014 at 1:10 PM, Andrew Wilkins <[email protected]> wrote: > On Fri, Aug 22, 2014 at 11:57 AM, John Meinel <[email protected]> > wrote: >> 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.
Yes, the Server needs to finish with an error that communicates the need to restart upwards. In general a facade has references to a number of things, originally provided by the Server, that it needs to do its job; this STM like just another dependency like State, Authorizer, etc. > 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. Well, the tomb is kinda private. Least work in the *short* term, maybe, but... no. ;p At the moment the FacadeFactory type takes a *State, a Resources, and an Authorizer (plus a string id): it would not be suitable to *just* add another parameter to that type, 4 is enough, but it would be fine to add a parameter type and add a Restarter field there. >> 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? In particular, we want to roll back failed schema upgrades. Cheers William -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
