[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Client_result vs client_error
- From: Lili Nader <lnader redhat com>
- To: Clayton Coleman <ccoleman redhat com>
- Cc: dev <dev lists openshift redhat com>
- Subject: Re: Client_result vs client_error
- Date: Thu, 11 Jul 2013 17:19:24 -0400 (EDT)
So you are saying the messages currently classified as info are superfluous for the UI? We should perhaps fix that problem instead of reclassifying the client_message as warning.
----- Original Message -----
From: "Clayton Coleman" <ccoleman redhat com>
To: "Lili Nader" <lnader redhat com>
Cc: "dev" <dev lists openshift redhat com>, "Hiro Asari" <hasari redhat com>, "Jhon Honce" <jhonce redhat com>, "Abhishek Gupta" <abhgupta redhat com>, "Daniel McPherson" <dmcphers redhat com>, "Jessica Forrester" <jforrest redhat com>, "Jordan Liggitt" <jliggitt redhat com>
Sent: Thursday, July 11, 2013 12:54:31 PM
Subject: Re: Client_result vs client_error
On Jul 11, 2013, at 3:51 PM, Lili Nader <lnader redhat com> wrote:
> I agree we need to do some work to streamline the messaging from node -> broker -> UI/CLI.
> Broker -> UI/CLI
> I'm not sure mapping client_message to :warning is correct. I think the current mapping of client_message -> :info is correct. I think the UI/CLI should display all messages with severity info or above.
The UI knows that its doing a certain type of operation - so the info messages the broker sends are not useful and need to be hidden. If the message has to be shown, it has to be returned at higher than info level.
> I also don't think the broker should filter out any messages based on exit code. I believe the current behavior of classifying messages and sending them to the client is correct. The client should decide based on severity which messages to display to user (In my opinion anything with info and above severity)
This is what the old API did - we never actually implemented that correctly in the new client code and rest API.
> If there are instances where displaying messages with :info and above are confusing to the user then we should address those scenarios.
> Node -> Broker
> The message from node to broker can benefit from streamlining. I think we should stick with the following categories.
> - debug
> - info - today is message
> - result - All formatted data like CART_DATA, APP_INFO, etc should be placed here. If this information should not be passed back to the client then maybe a flag can be added to indicate that.
> - error
> It will greatly help broker to return the appropriate HTTP status code to client, if we can break down the errors from node into the following categories:
> 1. Client
> a) Should be corrected and tried again. Like a validation error.
> b) Should not be attempted again. Like a permission error or an unsupported action.
> 2. Server
> a) Temporary problem and should be retried
> b) Everything else
> ----- Original Message -----
> From: "Clayton Coleman" <ccoleman redhat com>
> To: "Hiro Asari" <hasari redhat com>, "Jhon Honce" <jhonce redhat com>, "Abhishek Gupta" <abhgupta redhat com>, "Daniel McPherson" <dmcphers redhat com>, "Lili Nader" <lnader redhat com>
> Cc: "Jessica Forrester" <jforrest redhat com>, "Jordan Liggitt" <jliggitt redhat com>
> Sent: Wednesday, July 10, 2013 7:02:53 AM
> Subject: Client_result vs client_error
> https://bugzilla.redhat.com/show_bug.cgi?id=981780 talks about client_error not being displayed. Dan explained to me what the original intent was:
> client_result is returned to the client via the REST API on success, and on error IF no client_error was sent
> client_error if specified during a script execution that fails (returns non-zero exit) REPLACES all client_results in what is returned to the user
> client_message if specified, is ALWAYS returned to the client and the client should ALWAYS show it
> Our current severity levels in the REST API should be:
> The CLI will not display messages of "debug" or "info" unless the user passes -d.
> We need to check that the behavior of the node, broker, and UI matches the following:
> * When client_message is received by the broker, it should be added to the messages array returned to the client at severity "warning" and field "nil".
> * On a successful operation, the combined client_result's for a cartridge should be returned as a single message with severity "result" and field "nil" (in API > 1.5)
> * On a failed operation, the broker should return EITHER the combined client_errors for a cartridge as a single message with severity "error" and field "nil", OR it should return the combined client_results as a single message with severity "error" and field "nil". It should not return both at the same time.
> Any bugs we have open should probably be checked to verify that this is what a) the cartridges are doing, b) what the broker is doing, and I'll check the UI to verify that it is doing that as well.
> Clayton Coleman | OpenShift UI lead
> (919)754-4982 - Raleigh Tower - 16/N145
[Date Prev][Date Next] [Thread Prev][Thread Next]