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

sregistry limit questions #326

Open
danmons opened this issue Oct 28, 2020 · 7 comments
Open

sregistry limit questions #326

danmons opened this issue Oct 28, 2020 · 7 comments

Comments

@danmons
Copy link

danmons commented Oct 28, 2020

I have a local sregistry running, and have the following config items:

# grep LIMIT shub/settings/config.py 
USER_COLLECTION_LIMIT = 0
CONTAINER_WEEKLY_GET_LIMIT = 99999
COLLECTION_WEEKLY_GET_LIMIT = 99999
SREGISTRY_GOOGLE_BUILD_LIMIT = 9999
VIEW_RATE_LIMIT = "999999/1d"
VIEW_RATE_LIMIT_BLOCK = ( False )

However when things get busy, get the following error from "singularity push" operations:

FATAL:   Unable to push image to library: request did not succeed: http status code: 429

A simple loop will have me limited in about 20 push requests over the course of 15-30 minutes. Restarting the sregistry docker container resets the limits.

This is a private facing registry for an internal user group, and I don't want to impose any limits on them at all. Is there a config item I've missed? I've attempted to set some of those values to "0" as well, with no luck (either the container won't start, or the problem doesn't go away).

@vsoch
Copy link
Member

vsoch commented Oct 28, 2020

You could try setting RATELIMIT_ENABLE to False https://django-ratelimit.readthedocs.io/en/stable/settings.html#ratelimit-enable.

@danmons
Copy link
Author

danmons commented Oct 28, 2020

Many thanks for the speedy reply. Unfortunately that didn't change anything for me.

My test loop simply pushes the same container over itself continuously with a 1 second sleep between pushes. Within 7-10 minutes and 15-20 containers pushed, the 429 error returns.

@vsoch
Copy link
Member

vsoch commented Oct 28, 2020

Have you tried setting the limit to None, and block to False? And also make sure to reset containers and clear the cache you are using.

@vsoch
Copy link
Member

vsoch commented Oct 28, 2020

Also, we should double check the version - as of 3.0.0 the RatelimitMixin is deprecated in favor of using method_decorator.

@vsoch
Copy link
Member

vsoch commented Oct 30, 2020

heyo! Just checking in. Did setting to None have any luck?

@danmons
Copy link
Author

danmons commented Nov 1, 2020

Hi,

The settings didn't take, but I haven't had a chance to update the containers yet. I have a window to make that change tomorrow, so I'll get back to you as soon as I've completed that.

@vsoch
Copy link
Member

vsoch commented Nov 1, 2020

Sounds good! We would want to check:

  • the version of ratelimit
  • confirm that you've restarted the containers

And we might need to look into if the ratelimit module uses a cache or some database model to determine rules - it could be that you make a change and then it's not reflected because the database / cache still sees old requests.

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

No branches or pull requests

2 participants