New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log S3 API error message #30126

Merged
merged 1 commit into from Jan 4, 2016

Conversation

Projects
None yet
2 participants
@stanislavb
Contributor

stanislavb commented Jan 2, 2016

Background

When the S3 API returns for example code 403, it is hard to guess what went wrong without looking at the more verbose message, as seen for example in #29912.

Change contents

When S3 API returns an error code in the 400 or 500 range, put message contents into debug log for easier troubleshooting.

Requests doesn't raise HTTPError automatically - for that raise_for_status() is commonly used. Therefore the try clause never caught any exceptions.

This change replaces the never activated except block with a response code check, as seen in utils/aws.py

Q&A

  • Should we raise an error instead?
    Potentially Salt will generate a big amount of these log lines, for example when updating every single states file from S3. It is less scary to put it in debug log.
  • Why did we lose the "return False"?
    It is inconsistent with the error handling below where return value does not matter.
  • Why aren't we alerting the user that something went wrong?
    That requires a go-through through the whole s3.py to see which log.debug() should really be log.error() and is left for a future change.
Log S3 API error message
Background: When the S3 API returns for example code 403, it is hard to
guess what went wrong without looking at the more verbose message, as
seen for example in #29912.

When S3 API returns an error code in the 400 or 500 range, put message
contents into debug log for easier troubleshooting.

Requests doesn't raise HTTPError automatically - for that
raise_for_status() is commonly used. Therefore the try clause never
caught any exceptions.

This change replaces the never activated except block with a response
code check, as seen in utils/aws.py

Q&A:
Should we raise an error instead? Potentially Salt will generate a big
amount of these log lines, for example when updating every single states
file from S3. It is less scary to put it in debug log.

Why did we lose the "return False"? It is inconsistent with the error
handling below where return value does not matter.

Why aren't we alerting the user that something went wrong? That requires
a go-through through the whole s3.py to see which log.debug() should
really be log.error() and is left for a future change.
@cachedout

This comment has been minimized.

Show comment
Hide comment
@cachedout

cachedout Jan 4, 2016

Contributor

Hi @stanislavb

This all seems very sensible. Thank you for the very thorough PR. It's appreciated!

Contributor

cachedout commented Jan 4, 2016

Hi @stanislavb

This all seems very sensible. Thank you for the very thorough PR. It's appreciated!

cachedout added a commit that referenced this pull request Jan 4, 2016

@cachedout cachedout merged commit c06671a into saltstack:2015.8 Jan 4, 2016

3 of 5 checks passed

default Merged build finished.
Details
jenkins/salt-pr-linode-ubuntu14.04-n Salt PR - Linode Ubuntu 14.04 #3813 — FAILURE
Details
jenkins/salt-pr-clone Salt PR - Clone Repository #12471 — SUCCESS
Details
jenkins/salt-pr-lint-n Salt PR - Code Lint #12170 — SUCCESS
Details
jenkins/salt-pr-rs-cent7-n Salt PR - RS CentOS 7 #11053 — SUCCESS
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment