[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Client_result vs client_error



Ok. Based on the examples you have given then the client_message is indeed a warning.  

Also on the UI/CLI side you may want to decide to show the info messages based on the HTTP status code.  i.e. If 2xx then ignore info otherwise display.  That way the user won't miss out on any messages that may be useful in figuring out what went wrong. I am thinking of a case where multiple actions have taken place on the node from a single request.  On the broker side we currently accumulate all messages from the node and send it back in the response. Just a thought.

Lili



----- 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 2:47:43 PM
Subject: Re: Client_result vs client_error



On Jul 11, 2013, at 5:19 PM, Lili Nader <lnader redhat com> wrote:

> 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.  
> Lili

It's intentional, because info (as used today) is basically the broker saying "yup, I did what you asked".  Since we (the client) know what the broker should be doing, we ignore it.  All broker messages that convey the same info as the operation (create, delete, update) are things that advanced clients don't need.  It's absolutely "info" - useful, but not adding anything special.  Thus, anything that the broker says is as important as "application created" will and should get ignored by clients that are anything more complicated than very simple request response loops.

Result is special - it's how the cart says "your operation did something you need to know about".  It's not warning, because there's no danger.

The original intent of client_message was "tell the client something important that is unrelated to results".  For example, a warning that the cart is going to be deprecated in the future.  Sending back an info message there would mean the broker would need to change the level of its messages to something lower.  So message (as it was originally implemented) needs to be higher than info.


> 
> 
> 
> ----- 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:
>> 
>> Error
>> 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
>> 
>> Lili
>> 
>> 
>> 
>> ----- 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:
>> 
>> debug
>> info
>> result
>> warning
>> error
>> 
>> 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]   [Thread Index] [Date Index] [Author Index]