Skip to content
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

Revert "nginx.conf: Use equal values for client_body_buffer_size and client_max_body_size to avoid writing big files to disk" #29

Merged
2 commits merged into from
Dec 14, 2017

Conversation

dfunckt
Copy link
Member

@dfunckt dfunckt commented Dec 14, 2017

Revert commit 4159eb5 due to nginx.conf already specifying a client_max_body_size that conflicts with the newly specified one.

In fact, client_max_body_size is set to 0, disabling any limits, therefore preventing the registry from responding with 413 when a client tries to upload large layers.

This needs further investigation to determine how Docker behaves with various registry settings, but in the meantime this needs to be reverted.

Change-Type: patch
Connects-To: #8
See: #28
HQ: https://github.com/resin-io/hq/issues/1115


---- Autogenerated Waffleboard Connection: Connects to #8

…client_max_body_size to avoid writing big files to disk"

Revert commit 4159eb5 due to nginx.conf already specifying a client_max_body_size that conflicts with the newly specified one.

In fact, client_max_body_size is set to `0`, disabling any limits, therefore preventing the registry from responding with 413 when a client tries to upload large layers.

This needs further investigation to determine how Docker behaves with various registry settings, but in the meantime this needs to be reverted.

Change-Type: patch
Connects-To: #8
HQ: balena-io/balena-io#1115
Copy link

@pcarranzav pcarranzav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh! I don't know how I missed it before...

@dfunckt
Copy link
Member Author

dfunckt commented Dec 14, 2017

Well, happy as I was that we might have found the cause, I missed it as well :)

@pcarranzav
Copy link

I think this confirms that this is the cause though - but it means we can't fix it like this, and probably just need to ensure the server has enough disk space for buffering... right?

@dfunckt
Copy link
Member Author

dfunckt commented Dec 14, 2017

Yeah, we probably need to add storage to the registries for temp files.

@dfunckt
Copy link
Member Author

dfunckt commented Dec 14, 2017

But I first want to try removing client_max_body_size = 0 and test how various Docker versions behave when given 413. We might get away without having to assign storage at all.

@ghost ghost merged commit d817e01 into master Dec 14, 2017
@ghost ghost deleted the revert-pr-28 branch December 14, 2017 11:36
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants