-
Notifications
You must be signed in to change notification settings - Fork 898
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
Purging of ContainerQuota & ContainerQuotaItem #17167
Conversation
Both are necessary because ContainerQuotaItem may be archived due to edits to parent ContainerQuota that is still alive. https://bugzilla.redhat.com/show_bug.cgi?id=1504560
Checked commit cben@022e152 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Just that one statement about the implications of using purge_associated_records
where(arel_table[:deleted_on].lteq(older_than)) | ||
end | ||
|
||
def purge_associated_records(ids) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reminder: adding purge_associated_records
currently causes us to retrieve all ids that are deleted from container quota. If the number of records is low, then this is not a problem.
If there are a bunch of records to be deleted, we may want to come up with another way to clear out these associated 2 tables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect few ContainerQuota records purged — only when admins delete the whole quota definition in a project (*) — but possibly many child ContainerQuotaItem records to purge (these may be archived on inventory changes, may become comparable to ContainerGroup table).
(*) Technically it's possible to have an arbitrary number of quotas in a project, but in practice 0 or 1 will be common, unlikely to be over 4.
I'm doing this to avoid leaving orphan items. Since items should get archived when parent quota gets archived, we could also avoid orphans by giving items a lower lifetime, e.g. 5.month vs 6.month. But I prefer ensuring DB consistency by explicit code over "it happens to work if tuned correctly" :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Scratch that, purge_associated_records
is also needed to avoid leaving orphan ContainerQuotaScopes, no alternative there.
ping — anything more to do here or can someone merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM... @kbrock if you're happy can you merge?
Purging of ContainerQuota & ContainerQuotaItem (cherry picked from commit 388f266) https://bugzilla.redhat.com/show_bug.cgi?id=1559544
Gaprindashvili backport details:
|
Both purgings are necessary because ContainerQuotaItem may be archived due to edits to parent ContainerQuota that remains alive. This case wouldn't be covered if we only did ContainerQuota::Purging (that also purges associated items).
Followup to quota archiving PR #16722.
Purging mostly cargo-culted from #14322.
Chose to separate setting for how long to keep quotas from setting for other container entities, since we don't really know how fast quota tables will grow at large scale, and might need to tune this down...
https://bugzilla.redhat.com/show_bug.cgi?id=1504560
@miq-bot add-label enhancement, gaprindashvili/yes
@zeari Please review.