Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-16 Thread Flavio Percoco
On 09/16/2014 01:10 AM, Clint Byrum wrote:
 Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
 On 09/15/2014 07:00 PM, Mark Washenberger wrote:
 Hi there logging experts,

 We've recently had a little disagreement in the glance team about the
 appropriate log levels for http requests that end up failing due to user
 errors. An example would be a request to get an image that does not
 exist, which results in a 404 Not Found request.

 On one hand, this event is an error, so DEBUG or INFO seem a little too
 low. On the other hand, this error doesn't generally require any kind of
 operator investigation or indicate any actual failure of the service, so
 perhaps it is excessive to log it at WARN or ERROR.

 Please provide feedback to help us resolve this dispute if you feel you can!

 My feeling is this is an INFO level. There is really nothing the admin
 should care about here.
 
 Agree with Sean. INFO are useful for investigations. WARN and ERROR are
 cause for alarm.

+1 this is what we do in Zaqar as well.


-- 
@flaper87
Flavio Percoco

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-16 Thread Kuvaja, Erno
 -Original Message-
 From: Flavio Percoco [mailto:fla...@redhat.com]
 Sent: 16 September 2014 10:08
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
 level
 guidelines
 
 On 09/16/2014 01:10 AM, Clint Byrum wrote:
  Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
  On 09/15/2014 07:00 PM, Mark Washenberger wrote:
  Hi there logging experts,
 
  We've recently had a little disagreement in the glance team about
  the appropriate log levels for http requests that end up failing due
  to user errors. An example would be a request to get an image that
  does not exist, which results in a 404 Not Found request.
 
  On one hand, this event is an error, so DEBUG or INFO seem a little
  too low. On the other hand, this error doesn't generally require any
  kind of operator investigation or indicate any actual failure of the
  service, so perhaps it is excessive to log it at WARN or ERROR.
 
  Please provide feedback to help us resolve this dispute if you feel you
 can!
 
  My feeling is this is an INFO level. There is really nothing the
  admin should care about here.
 
  Agree with Sean. INFO are useful for investigations. WARN and ERROR
  are cause for alarm.
 
 +1 this is what we do in Zaqar as well.
 
 
 --
 @flaper87
 Flavio Percoco
 

I think the debate here does not only limit to 404s. By the logging guidelines 
INFO level messages should not contain any error related messages but rather 
stuff like certain components starting/stopping, config info, etc. WARN should 
not be anything that gets the ops pulled out of bed and so on. 

Also all information that would be in interest of ops should be logged INFO+.

Now if we are logging user errors as WARN that makes the environment 
supportable even if the logging has been set as high as WARN cleaning the 
output a lot (as INFO shouldn't contain anything out of order anyways). Current 
situation is that logging at DEBUG level is the only option to get the needed 
information to actually run the services and get the data needed to support it 
as well. If we log user errors on INFO we get one step higher but we still have 
all that clutter like every single request in the logs and if that's the 
direction we want to go, we should revisit our logging guidelines as well.

Thus my two euro cents goes towards WARN rather than debug and definitely not 
INFO.

- Erno (jokke) Kuvaja

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-16 Thread Sean Dague
On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
 -Original Message-
 From: Flavio Percoco [mailto:fla...@redhat.com]
 Sent: 16 September 2014 10:08
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
 level
 guidelines

 On 09/16/2014 01:10 AM, Clint Byrum wrote:
 Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
 On 09/15/2014 07:00 PM, Mark Washenberger wrote:
 Hi there logging experts,

 We've recently had a little disagreement in the glance team about
 the appropriate log levels for http requests that end up failing due
 to user errors. An example would be a request to get an image that
 does not exist, which results in a 404 Not Found request.

 On one hand, this event is an error, so DEBUG or INFO seem a little
 too low. On the other hand, this error doesn't generally require any
 kind of operator investigation or indicate any actual failure of the
 service, so perhaps it is excessive to log it at WARN or ERROR.

 Please provide feedback to help us resolve this dispute if you feel you
 can!

 My feeling is this is an INFO level. There is really nothing the
 admin should care about here.

 Agree with Sean. INFO are useful for investigations. WARN and ERROR
 are cause for alarm.

 +1 this is what we do in Zaqar as well.


 --
 @flaper87
 Flavio Percoco

 
 I think the debate here does not only limit to 404s. By the logging 
 guidelines INFO level messages should not contain any error related messages 
 but rather stuff like certain components starting/stopping, config info, etc. 
 WARN should not be anything that gets the ops pulled out of bed and so on. 
 
 Also all information that would be in interest of ops should be logged INFO+.
 
 Now if we are logging user errors as WARN that makes the environment 
 supportable even if the logging has been set as high as WARN cleaning the 
 output a lot (as INFO shouldn't contain anything out of order anyways). 
 Current situation is that logging at DEBUG level is the only option to get 
 the needed information to actually run the services and get the data needed 
 to support it as well. If we log user errors on INFO we get one step higher 
 but we still have all that clutter like every single request in the logs and 
 if that's the direction we want to go, we should revisit our logging 
 guidelines as well.
 
 Thus my two euro cents goes towards WARN rather than debug and definitely not 
 INFO.

Part of it is how often you expect things to happen as well. Remember
glanceclient opperates in the context of other processes. When it hits
a 404 in Glance, it's not running in the glance context, it's running in
the Nova context. Which means it needs to think of itself in that context.

In that context we got the exception back from Glance, we know the image
wasn't there. And we know whether or not that's a problem (glanceclient
actually has no idea if it's a problem or not, we might be checking to
make sure a thing isn't there, and success for us is the 404).

So actually, I'm back to Jay on this, it should be DEBUG. Nova (or
whoever the caller is) can decide if the issue warents something larger
than that.

This is really the biggest issue with logging in the clients, people
don't think about the context that they are running in.

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-16 Thread Kuvaja, Erno
 -Original Message-
 From: Sean Dague [mailto:s...@dague.net]
 Sent: 16 September 2014 12:40
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
 level
 guidelines
 
 On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
  -Original Message-
  From: Flavio Percoco [mailto:fla...@redhat.com]
  Sent: 16 September 2014 10:08
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
  log level guidelines
 
  On 09/16/2014 01:10 AM, Clint Byrum wrote:
  Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
  On 09/15/2014 07:00 PM, Mark Washenberger wrote:
  Hi there logging experts,
 
  We've recently had a little disagreement in the glance team about
  the appropriate log levels for http requests that end up failing
  due to user errors. An example would be a request to get an image
  that does not exist, which results in a 404 Not Found request.
 
  On one hand, this event is an error, so DEBUG or INFO seem a
  little too low. On the other hand, this error doesn't generally
  require any kind of operator investigation or indicate any actual
  failure of the service, so perhaps it is excessive to log it at WARN or
 ERROR.
 
  Please provide feedback to help us resolve this dispute if you
  feel you
  can!
 
  My feeling is this is an INFO level. There is really nothing the
  admin should care about here.
 
  Agree with Sean. INFO are useful for investigations. WARN and ERROR
  are cause for alarm.
 
  +1 this is what we do in Zaqar as well.
 
 
  --
  @flaper87
  Flavio Percoco
 
 
  I think the debate here does not only limit to 404s. By the logging 
  guidelines
 INFO level messages should not contain any error related messages but
 rather stuff like certain components starting/stopping, config info, etc.
 WARN should not be anything that gets the ops pulled out of bed and so on.
 
  Also all information that would be in interest of ops should be logged
 INFO+.
 
  Now if we are logging user errors as WARN that makes the environment
 supportable even if the logging has been set as high as WARN cleaning the
 output a lot (as INFO shouldn't contain anything out of order anyways).
 Current situation is that logging at DEBUG level is the only option to get the
 needed information to actually run the services and get the data needed to
 support it as well. If we log user errors on INFO we get one step higher but
 we still have all that clutter like every single request in the logs and if 
 that's
 the direction we want to go, we should revisit our logging guidelines as well.
 
  Thus my two euro cents goes towards WARN rather than debug and
 definitely not INFO.
 
 Part of it is how often you expect things to happen as well. Remember
 glanceclient opperates in the context of other processes. When it hits a 404
 in Glance, it's not running in the glance context, it's running in the Nova
 context. Which means it needs to think of itself in that context.
 
 In that context we got the exception back from Glance, we know the image
 wasn't there. And we know whether or not that's a problem (glanceclient
 actually has no idea if it's a problem or not, we might be checking to make
 sure a thing isn't there, and success for us is the 404).
 
 So actually, I'm back to Jay on this, it should be DEBUG. Nova (or whoever the
 caller is) can decide if the issue warents something larger than that.
 
 This is really the biggest issue with logging in the clients, people don't 
 think
 about the context that they are running in.
 
   -Sean
 
 --
 Sean Dague
 http://dague.net
 

Sean,

I'm not sure if we were specific enough here. Not talking about client but the 
server logging. So how we should log events like client trying to change 
protected properties, access non existing image, create duplicate image IDs, 
etc.

So for example if Nova is trying to access image that does not exist should we 
ignore it on Glance side or when the user tries to do something that does not 
succeed. In my point of view it makes life much easier if we have information 
where the request failed rather than just a wsgi return code or having to run 
the system on DEBUG logging to get that information.

- Erno

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-16 Thread Sean Dague
On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
 -Original Message-
 From: Sean Dague [mailto:s...@dague.net]
 Sent: 16 September 2014 12:40
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
 level
 guidelines

 On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
 -Original Message-
 From: Flavio Percoco [mailto:fla...@redhat.com]
 Sent: 16 September 2014 10:08
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
 log level guidelines

 On 09/16/2014 01:10 AM, Clint Byrum wrote:
 Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
 On 09/15/2014 07:00 PM, Mark Washenberger wrote:
 Hi there logging experts,

 We've recently had a little disagreement in the glance team about
 the appropriate log levels for http requests that end up failing
 due to user errors. An example would be a request to get an image
 that does not exist, which results in a 404 Not Found request.

 On one hand, this event is an error, so DEBUG or INFO seem a
 little too low. On the other hand, this error doesn't generally
 require any kind of operator investigation or indicate any actual
 failure of the service, so perhaps it is excessive to log it at WARN or
 ERROR.

 Please provide feedback to help us resolve this dispute if you
 feel you
 can!

 My feeling is this is an INFO level. There is really nothing the
 admin should care about here.

 Agree with Sean. INFO are useful for investigations. WARN and ERROR
 are cause for alarm.

 +1 this is what we do in Zaqar as well.


 --
 @flaper87
 Flavio Percoco


 I think the debate here does not only limit to 404s. By the logging 
 guidelines
 INFO level messages should not contain any error related messages but
 rather stuff like certain components starting/stopping, config info, etc.
 WARN should not be anything that gets the ops pulled out of bed and so on.

 Also all information that would be in interest of ops should be logged
 INFO+.

 Now if we are logging user errors as WARN that makes the environment
 supportable even if the logging has been set as high as WARN cleaning the
 output a lot (as INFO shouldn't contain anything out of order anyways).
 Current situation is that logging at DEBUG level is the only option to get 
 the
 needed information to actually run the services and get the data needed to
 support it as well. If we log user errors on INFO we get one step higher but
 we still have all that clutter like every single request in the logs and if 
 that's
 the direction we want to go, we should revisit our logging guidelines as 
 well.

 Thus my two euro cents goes towards WARN rather than debug and
 definitely not INFO.

 Part of it is how often you expect things to happen as well. Remember
 glanceclient opperates in the context of other processes. When it hits a 
 404
 in Glance, it's not running in the glance context, it's running in the Nova
 context. Which means it needs to think of itself in that context.

 In that context we got the exception back from Glance, we know the image
 wasn't there. And we know whether or not that's a problem (glanceclient
 actually has no idea if it's a problem or not, we might be checking to make
 sure a thing isn't there, and success for us is the 404).

 So actually, I'm back to Jay on this, it should be DEBUG. Nova (or whoever 
 the
 caller is) can decide if the issue warents something larger than that.

 This is really the biggest issue with logging in the clients, people don't 
 think
 about the context that they are running in.

  -Sean

 --
 Sean Dague
 http://dague.net

 
 Sean,
 
 I'm not sure if we were specific enough here. Not talking about client but 
 the server logging. So how we should log events like client trying to change 
 protected properties, access non existing image, create duplicate image IDs, 
 etc.
 
 So for example if Nova is trying to access image that does not exist should 
 we ignore it on Glance side or when the user tries to do something that does 
 not succeed. In my point of view it makes life much easier if we have 
 information where the request failed rather than just a wsgi return code or 
 having to run the system on DEBUG logging to get that information.

Glance client throws an ERROR on 404 from Glance server -
http://logs.openstack.org/81/120781/4/check/check-tempest-dsvm-full/90cb640/logs/screen-n-api.txt.gz?level=ERROR

Glance server does not -
http://logs.openstack.org/81/120781/4/check/check-tempest-dsvm-full/90cb640/logs/screen-g-api.txt.gz?level=ERROR

Which is why I assumed this was where the conversation started.

On the server side this should be an INFO with 404 recorded as the wsgi
request.

On the client this should be debug.

Just to get a look at how completely confusing the current scenario is,
lets dive through the logs about what should be changed.

Inside glance you also need to address client vs. server. For instance -
http

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-16 Thread Kuvaja, Erno
 -Original Message-
 From: Sean Dague [mailto:s...@dague.net]
 Sent: 16 September 2014 15:56
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
 level
 guidelines
 
 On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
  -Original Message-
  From: Sean Dague [mailto:s...@dague.net]
  Sent: 16 September 2014 12:40
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
  log level guidelines
 
  On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
  -Original Message-
  From: Flavio Percoco [mailto:fla...@redhat.com]
  Sent: 16 September 2014 10:08
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [glance][all] Help with interpreting
  the log level guidelines
 
  On 09/16/2014 01:10 AM, Clint Byrum wrote:
  Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
  On 09/15/2014 07:00 PM, Mark Washenberger wrote:
  Hi there logging experts,
 
  We've recently had a little disagreement in the glance team
  about the appropriate log levels for http requests that end up
  failing due to user errors. An example would be a request to get
  an image that does not exist, which results in a 404 Not Found
 request.
 
  On one hand, this event is an error, so DEBUG or INFO seem a
  little too low. On the other hand, this error doesn't generally
  require any kind of operator investigation or indicate any
  actual failure of the service, so perhaps it is excessive to log
  it at WARN or
  ERROR.
 
  Please provide feedback to help us resolve this dispute if you
  feel you
  can!
 
  My feeling is this is an INFO level. There is really nothing the
  admin should care about here.
 
  Agree with Sean. INFO are useful for investigations. WARN and
  ERROR are cause for alarm.
 
  +1 this is what we do in Zaqar as well.
 
 
  --
  @flaper87
  Flavio Percoco
 
 
  I think the debate here does not only limit to 404s. By the logging
  guidelines
  INFO level messages should not contain any error related messages but
  rather stuff like certain components starting/stopping, config info, etc.
  WARN should not be anything that gets the ops pulled out of bed and so
 on.
 
  Also all information that would be in interest of ops should be
  logged
  INFO+.
 
  Now if we are logging user errors as WARN that makes the environment
  supportable even if the logging has been set as high as WARN cleaning
  the output a lot (as INFO shouldn't contain anything out of order
 anyways).
  Current situation is that logging at DEBUG level is the only option
  to get the needed information to actually run the services and get
  the data needed to support it as well. If we log user errors on INFO
  we get one step higher but we still have all that clutter like every
  single request in the logs and if that's the direction we want to go, we
 should revisit our logging guidelines as well.
 
  Thus my two euro cents goes towards WARN rather than debug and
  definitely not INFO.
 
  Part of it is how often you expect things to happen as well. Remember
  glanceclient opperates in the context of other processes. When it
  hits a 404 in Glance, it's not running in the glance context, it's
  running in the Nova context. Which means it needs to think of itself in
 that context.
 
  In that context we got the exception back from Glance, we know the
  image wasn't there. And we know whether or not that's a problem
  (glanceclient actually has no idea if it's a problem or not, we might
  be checking to make sure a thing isn't there, and success for us is the 
  404).
 
  So actually, I'm back to Jay on this, it should be DEBUG. Nova (or
  whoever the caller is) can decide if the issue warents something larger
 than that.
 
  This is really the biggest issue with logging in the clients, people
  don't think about the context that they are running in.
 
 -Sean
 
  --
  Sean Dague
  http://dague.net
 
 
  Sean,
 
  I'm not sure if we were specific enough here. Not talking about client but
 the server logging. So how we should log events like client trying to change
 protected properties, access non existing image, create duplicate image IDs,
 etc.
 
  So for example if Nova is trying to access image that does not exist should
 we ignore it on Glance side or when the user tries to do something that does
 not succeed. In my point of view it makes life much easier if we have
 information where the request failed rather than just a wsgi return code or
 having to run the system on DEBUG logging to get that information.
 
 Glance client throws an ERROR on 404 from Glance server -
 http://logs.openstack.org/81/120781/4/check/check-tempest-dsvm-
 full/90cb640/logs/screen-n-api.txt.gz?level=ERROR
 
 Glance server does not -
 http://logs.openstack.org/81/120781/4/check/check-tempest-dsvm-
 full/90cb640/logs/screen-g-api.txt.gz?level=ERROR
 
 Which is why I assumed this was where the conversation started

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-16 Thread Sean Dague
On 09/16/2014 12:07 PM, Kuvaja, Erno wrote:
 -Original Message-
 From: Sean Dague [mailto:s...@dague.net]
 Sent: 16 September 2014 15:56
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
 level
 guidelines

 On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
 -Original Message-
 From: Sean Dague [mailto:s...@dague.net]
 Sent: 16 September 2014 12:40
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
 log level guidelines

 On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
 -Original Message-
 From: Flavio Percoco [mailto:fla...@redhat.com]
 Sent: 16 September 2014 10:08
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting
 the log level guidelines

 On 09/16/2014 01:10 AM, Clint Byrum wrote:
 Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
 On 09/15/2014 07:00 PM, Mark Washenberger wrote:
 Hi there logging experts,

 We've recently had a little disagreement in the glance team
 about the appropriate log levels for http requests that end up
 failing due to user errors. An example would be a request to get
 an image that does not exist, which results in a 404 Not Found
 request.

 On one hand, this event is an error, so DEBUG or INFO seem a
 little too low. On the other hand, this error doesn't generally
 require any kind of operator investigation or indicate any
 actual failure of the service, so perhaps it is excessive to log
 it at WARN or
 ERROR.

 Please provide feedback to help us resolve this dispute if you
 feel you
 can!

 My feeling is this is an INFO level. There is really nothing the
 admin should care about here.

 Agree with Sean. INFO are useful for investigations. WARN and
 ERROR are cause for alarm.

 +1 this is what we do in Zaqar as well.


 --
 @flaper87
 Flavio Percoco


 I think the debate here does not only limit to 404s. By the logging
 guidelines
 INFO level messages should not contain any error related messages but
 rather stuff like certain components starting/stopping, config info, etc.
 WARN should not be anything that gets the ops pulled out of bed and so
 on.

 Also all information that would be in interest of ops should be
 logged
 INFO+.

 Now if we are logging user errors as WARN that makes the environment
 supportable even if the logging has been set as high as WARN cleaning
 the output a lot (as INFO shouldn't contain anything out of order
 anyways).
 Current situation is that logging at DEBUG level is the only option
 to get the needed information to actually run the services and get
 the data needed to support it as well. If we log user errors on INFO
 we get one step higher but we still have all that clutter like every
 single request in the logs and if that's the direction we want to go, we
 should revisit our logging guidelines as well.

 Thus my two euro cents goes towards WARN rather than debug and
 definitely not INFO.

 Part of it is how often you expect things to happen as well. Remember
 glanceclient opperates in the context of other processes. When it
 hits a 404 in Glance, it's not running in the glance context, it's
 running in the Nova context. Which means it needs to think of itself in
 that context.

 In that context we got the exception back from Glance, we know the
 image wasn't there. And we know whether or not that's a problem
 (glanceclient actually has no idea if it's a problem or not, we might
 be checking to make sure a thing isn't there, and success for us is the 
 404).

 So actually, I'm back to Jay on this, it should be DEBUG. Nova (or
 whoever the caller is) can decide if the issue warents something larger
 than that.

 This is really the biggest issue with logging in the clients, people
 don't think about the context that they are running in.

-Sean

 --
 Sean Dague
 http://dague.net


 Sean,

 I'm not sure if we were specific enough here. Not talking about client but
 the server logging. So how we should log events like client trying to change
 protected properties, access non existing image, create duplicate image IDs,
 etc.

 So for example if Nova is trying to access image that does not exist should
 we ignore it on Glance side or when the user tries to do something that does
 not succeed. In my point of view it makes life much easier if we have
 information where the request failed rather than just a wsgi return code or
 having to run the system on DEBUG logging to get that information.

 Glance client throws an ERROR on 404 from Glance server -
 http://logs.openstack.org/81/120781/4/check/check-tempest-dsvm-
 full/90cb640/logs/screen-n-api.txt.gz?level=ERROR

 Glance server does not -
 http://logs.openstack.org/81/120781/4/check/check-tempest-dsvm-
 full/90cb640/logs/screen-g-api.txt.gz?level=ERROR

 Which is why I assumed this was where the conversation started.

 On the server side this should be an INFO with 404 recorded

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-16 Thread Kuvaja, Erno
 -Original Message-
 From: Sean Dague [mailto:s...@dague.net]
 Sent: 16 September 2014 17:31
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
 level
 guidelines
 
 On 09/16/2014 12:07 PM, Kuvaja, Erno wrote:
  -Original Message-
  From: Sean Dague [mailto:s...@dague.net]
  Sent: 16 September 2014 15:56
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
  log level guidelines
 
  On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
  -Original Message-
  From: Sean Dague [mailto:s...@dague.net]
  Sent: 16 September 2014 12:40
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [glance][all] Help with interpreting
  the log level guidelines
 
  On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
  -Original Message-
  From: Flavio Percoco [mailto:fla...@redhat.com]
  Sent: 16 September 2014 10:08
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [glance][all] Help with interpreting
  the log level guidelines
 
  On 09/16/2014 01:10 AM, Clint Byrum wrote:
  Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
  On 09/15/2014 07:00 PM, Mark Washenberger wrote:
  Hi there logging experts,
 
  We've recently had a little disagreement in the glance team
  about the appropriate log levels for http requests that end up
  failing due to user errors. An example would be a request to
  get an image that does not exist, which results in a 404 Not
  Found
  request.
 
  On one hand, this event is an error, so DEBUG or INFO seem a
  little too low. On the other hand, this error doesn't
  generally require any kind of operator investigation or
  indicate any actual failure of the service, so perhaps it is
  excessive to log it at WARN or
  ERROR.
 
  Please provide feedback to help us resolve this dispute if you
  feel you
  can!
 
  My feeling is this is an INFO level. There is really nothing
  the admin should care about here.
 
  Agree with Sean. INFO are useful for investigations. WARN and
  ERROR are cause for alarm.
 
  +1 this is what we do in Zaqar as well.
 
 
  --
  @flaper87
  Flavio Percoco
 
 
  I think the debate here does not only limit to 404s. By the
  logging guidelines
  INFO level messages should not contain any error related messages
  but rather stuff like certain components starting/stopping, config info,
 etc.
  WARN should not be anything that gets the ops pulled out of bed and
  so
  on.
 
  Also all information that would be in interest of ops should be
  logged
  INFO+.
 
  Now if we are logging user errors as WARN that makes the
  environment
  supportable even if the logging has been set as high as WARN
  cleaning the output a lot (as INFO shouldn't contain anything out
  of order
  anyways).
  Current situation is that logging at DEBUG level is the only option
  to get the needed information to actually run the services and get
  the data needed to support it as well. If we log user errors on
  INFO we get one step higher but we still have all that clutter like
  every single request in the logs and if that's the direction we
  want to go, we
  should revisit our logging guidelines as well.
 
  Thus my two euro cents goes towards WARN rather than debug and
  definitely not INFO.
 
  Part of it is how often you expect things to happen as well.
  Remember glanceclient opperates in the context of other
  processes. When it hits a 404 in Glance, it's not running in the
  glance context, it's running in the Nova context. Which means it
  needs to think of itself in
  that context.
 
  In that context we got the exception back from Glance, we know the
  image wasn't there. And we know whether or not that's a problem
  (glanceclient actually has no idea if it's a problem or not, we
  might be checking to make sure a thing isn't there, and success for us is
 the 404).
 
  So actually, I'm back to Jay on this, it should be DEBUG. Nova (or
  whoever the caller is) can decide if the issue warents something
  larger
  than that.
 
  This is really the biggest issue with logging in the clients,
  people don't think about the context that they are running in.
 
   -Sean
 
  --
  Sean Dague
  http://dague.net
 
 
  Sean,
 
  I'm not sure if we were specific enough here. Not talking about
  client but
  the server logging. So how we should log events like client trying to
  change protected properties, access non existing image, create
  duplicate image IDs, etc.
 
  So for example if Nova is trying to access image that does not exist
  should
  we ignore it on Glance side or when the user tries to do something
  that does not succeed. In my point of view it makes life much easier
  if we have information where the request failed rather than just a
  wsgi return code or having to run the system on DEBUG logging to get that
 information.
 
  Glance client throws an ERROR on 404 from Glance server -
  http

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-16 Thread Jay Pipes

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.


-jay

 rather

than just a wsgi return code or having to run the system on DEBUG
logging to get that information.

- Erno

___ OpenStack-dev mailing
list OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-16 Thread Kuvaja, Erno


 -Original Message-
 From: Jay Pipes [mailto:jaypi...@gmail.com]
 Sent: 16 September 2014 18:10
 To: openstack-dev@lists.openstack.org
 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.
 
 -jay
 

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

- Erno

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-16 Thread Jay Pipes

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:
openstack-dev@lists.openstack.org 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.

-jay



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 
operator logs:


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.


-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-15 Thread Sean Dague
On 09/15/2014 07:00 PM, Mark Washenberger wrote:
 Hi there logging experts,
 
 We've recently had a little disagreement in the glance team about the
 appropriate log levels for http requests that end up failing due to user
 errors. An example would be a request to get an image that does not
 exist, which results in a 404 Not Found request.
 
 On one hand, this event is an error, so DEBUG or INFO seem a little too
 low. On the other hand, this error doesn't generally require any kind of
 operator investigation or indicate any actual failure of the service, so
 perhaps it is excessive to log it at WARN or ERROR.
 
 Please provide feedback to help us resolve this dispute if you feel you can!

My feeling is this is an INFO level. There is really nothing the admin
should care about here.

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-15 Thread Clint Byrum
Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
 On 09/15/2014 07:00 PM, Mark Washenberger wrote:
  Hi there logging experts,
  
  We've recently had a little disagreement in the glance team about the
  appropriate log levels for http requests that end up failing due to user
  errors. An example would be a request to get an image that does not
  exist, which results in a 404 Not Found request.
  
  On one hand, this event is an error, so DEBUG or INFO seem a little too
  low. On the other hand, this error doesn't generally require any kind of
  operator investigation or indicate any actual failure of the service, so
  perhaps it is excessive to log it at WARN or ERROR.
  
  Please provide feedback to help us resolve this dispute if you feel you can!
 
 My feeling is this is an INFO level. There is really nothing the admin
 should care about here.

Agree with Sean. INFO are useful for investigations. WARN and ERROR are
cause for alarm.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

2014-09-15 Thread Jay Pipes

On 09/15/2014 07:00 PM, Mark Washenberger wrote:

Hi there logging experts,

We've recently had a little disagreement in the glance team about the
appropriate log levels for http requests that end up failing due to user
errors. An example would be a request to get an image that does not
exist, which results in a 404 Not Found request.

On one hand, this event is an error, so DEBUG or INFO seem a little too
low.


But it's not an error. I mean, it's an error for the user, but the 
software (Glance) has not acted in a way that is either unrecoverable or 
requires action.


I think DEBUG is the appropriate level to log this. That said, standard 
WSGI logging dictates that there be a single INFO-level log line that 
logs the URI request made and the HTTP return code sent, so there should 
already be an INFO level log line that would have the 40X return code in it.


Best,
-jay

 On the other hand, this error doesn't generally require any kind of

operator investigation or indicate any actual failure of the service, so
perhaps it is excessive to log it at WARN or ERROR.

Please provide feedback to help us resolve this dispute if you feel you can!

Thanks,
markwash


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev