Triggering Server Restarts

[Andrew Wilkins]

On Tue, Aug 26, 2014 at 8:06 AM, William Reade <william.reade at canonical.com>
wrote:

> On Fri, Aug 22, 2014 at 1:10 PM, Andrew Wilkins
> <andrew.wilkins at canonical.com> wrote:
> > On Fri, Aug 22, 2014 at 11:57 AM, John Meinel <john at arbash-meinel.com>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140826/2f5c9026/attachment.html>