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

Re: Client_result vs client_error



Good point.  Info is very important for errors.

----- Original Message -----
> 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]