On 09/16/2014 02:04 PM, Kuvaja, Erno wrote:
-----Original Message----- From: Jay Pipes
[mailto:jaypi...@gmail.com] Sent: 16 September 2014 18:10 To:
email@example.com Subject: Re: [openstack-dev]
[glance][all] Help with interpreting the log level guidelines
On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
In my point of view it makes life much easier if we have
information where the request failed
The request did not fail. The HTTP request succeeded and Glance
returned a 404 Not Found. If the caller was expecting an image to
be there, but it wasn't, then it can log the 404 in whatever log
level is most appropriate.
The point is that DEBUG log level is appropriate for the
glanceclient logs, since the glanceclient doesn't know if a 404 is
something to be concerned about or not. To glanceclient, the call
succeeded. Communication with the Glance API server worked,
authentication worked, and the server returned successfully stating
that the image does not exist.
Still this is not about glanceclient logging. On that discussion I
fully agree that less is more what comes to logging.
When we try to update an image in the glance code and that fails
because the image is not there, I do not care where that gets stated
to the end user.
Yes you do. If the user understands the error message because it is
clear (i.e. "You tried to update an image record, but the image was not
found."), then the ops person does not get a ticket saying "the whole
system is down, please help me." Instead, they get a ticket saying "why
does this image no longer exist?"
> What I care about is that when the user starts
asking what happened, I don't get called up from the bed because the
ops responsible for the service have no idea.
Having the glanceclient log a WARN message in the log file if the image
was not found is not going to help the ops person in the slightest. That
information is already going to be in the ticket, with the description
"Why does this image no longer exist?". Having the following in the
WARN: Image XYZ not found.
is entirely useless to the operator. It offers them no further
information whatsoever versus what is already in the error message that
was returned to the user and likely copy/pasted into the help ticket.
> I also care that the
ops does not need to run through million lines of debugging logs just
because they would not get the info without. The reality is after all
that even in developer point of view the request did not fail, user
point of view it did.
We must keep in mind that somewhere out there is bunch of people
using these services outside of devstack who does not know the code
and how it behaves internally.
Yes, I keep that in mind. I was one of them.
> They see the log messages if any and
need to try to get the answers for the people who knows even less
about the internals.
There is a difference between log messages and error messages that are
returned to the user. You are, IMHO, confusing the two.
OpenStack-dev mailing list