Hi, Vijay.
On Apr 30, 2010, at 2:11 PM, Vijay Ramachandran wrote:
> We are not assuming that the server is going to be up and that the
> communication is reliable. We will try to send the command to the
> instance and get back results. If sending the command itself failed,
> we will flag it as one type of error that indicates something wrong
> with network or the server. If the command went through to the
> server but the command execution fails, we will get a detailed error
> (just as it happens now between CLI-DAS), and we will display this
> error. In either of the failure cases, we indicate to the caller
> (the CLI or GUI), that the server(s) where the replication failed
> need to be restarted.
If the server was up but the remote deploy command failed, why do we
expect restarting the server to fix the problem? We need to ask the
administrator to look at the problem and, perhaps, fix something with
the instance or the app. That's different from a remote deployment
failing because the DAS could not talk to the instance.
Reporting the error back to the admin client in such a case will
indeed be very helpful. Maybe this is in the "nice to have" category,
but it would also be really nice if the administrator could go to the
admin console and view the current status of each app on each instance
it is targeted for. If the remote deployment returned an error then
that error could be recorded as well as returned to the client.
This would be relatively easy to collect from the remote deployment
results; less easy for the DAS to get this after an instance restart.
That's why I expect it's a "nice to have" because I guess the DAS
would have to refresh that status for each app on an instance that
restarts.
Just a thought...
- Tim