Triggering Server Restarts

[William Reade]

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

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