Comment 11 for bug 1545092

Revision history for this message
Stuart McLaren (stuart-mclaren) wrote :

Thanks for raising this Brian.

Some overall observations.

1) The glance server paginates list responses (default images listed per response -- limit_param_default -- = 25), so the glance client also paginates image listing.
2) The maximum number of images per page is limited on the server side (default limit -- api_limit_max -- is 1000; this can be reduced by operators)
3) By default, user X cannot add images to user Y's listing [1]

So a user can just add (lots of) database records which won't be seen by other users.

Do we have hard data on how much user X can slow down listing (or other db intensive operations) for user Y?

Eg if we're using mysql, and user X creates 1,000,000 queued images, what is the effect -- in terms of slowdown -- on user Y's listing/other operations?

Is this a quota issue or a rate limit issue?

For example, would this quota patch be enough to mark as fixed? https://review.openstack.org/#/c/244573/

If a quota is in place a user can still create lots of database records by continuously creating and deleting queued images. Is that considered ok because the operator can purge deleted records?

[1] Marking images as public is admin only by default. The v1 issue of user A spamming user Y with shared images has it's own CVE.