On 4/30/10 1:24 PM, Tim Quinn wrote:
> 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.
Whenever a remote command on some instance fails (because of network
error or command execution failure or command getting timed out or ...),
some level of manual involvement will be required where the admin has to
see what went wrong with that instance. (As I had indicated in my
earlier mail, we will be able to distinguish a connection/network
related error from a command execution failure - hopefully it will be a
good clue to the admin). Once that problem is solved, for the "newly
repaired instance" to get the failed change, it has to synchronize
itself with DAS which will happen with the instance restart only. Hence
I mentioned that we will indicate that the server will require restart.
> 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...
Thanks - I will take note of it as a P3 task in the task list.
Vijay