On Tue, Aug 26, 2014 at 8:06 AM, William Reade <[email protected]> wrote:
> 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 > It doesn't have to be the tomb itself; it can be an interface which is implemented by a type wrapping a tomb. My point was that it seems unnecessary to add channels and signalling when we already have that with Runner+Tomb. > 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
