Tried verifying the bug on 4.5.0-0.nightly-2020-07-29-051236 and i see that i could create more than 10k projects and when the projects are created rangeallocations.data gets updated also when deletes happen rangeallocations.data gets deleted, but i see that value for (oc get rangeallocations scc-uid -o yaml | grep -o "/" | wc -l) before project creation and value after project deletion does not match i.e after 10K project deletion i see the value to be zero for the above query. @Tomas could you please confirm if the above is expected ? Thanks !! Raising needinfo on you since maciej is on leave.
we've synced offline, there is 8 hours reclaim period
Verified the bug with the payload below [ramakasturinarra@dhcp35-60 cucushift]$ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.5.0-0.nightly-2020-07-29-051236 True False 35h Cluster version is 4.5.0-0.nightly-2020-07-29-051236 Below are the steps which i have followed to verify the bug: =========================================================== 1) Install 4.5 cluster with the above payload 2) check rangeallocations.data by running the command below [ramakasturinarra@dhcp35-60 cucushift]$ oc get rangeallocations scc-uid -o yaml | grep -o "/" | wc -l 16 3) Created 10K projects 4) Ran the command below to check the rangeallocations.data [ramakasturinarra@dhcp35-60 cucushift]$ oc get rangeallocations scc-uid -o yaml | grep -o "/" | wc -l 1707 4) Deleted all the 10K projects and i see that the rangeallocations.data goes down to original value which is 16 after 4 hours of project deletions. [ramakasturinarra@dhcp35-60 cucushift]$ oc get rangeallocations scc-uid -o yaml | grep -o "/" | wc -l 16 P.s: Looks like reclaim period is 8 hours for rangeallocations.data to go come back to its original value once all the created projects are deleted. For more info please refer comment 4, also in QE test it took around 4-5 hours for the same. Based on the above moving the bug to verified state, thanks !!
Tried to test the bug again and this time i do not see any delay i.e need not have to wait for 8 hours for rangeallocations.data to be updated once all projects are deleted. Before 10K project creation: ================================= [ramakasturinarra@dhcp35-60 cucushift]$ oc get projects | wc -l 58 [ramakasturinarra@dhcp35-60 cucushift]$ oc get rangeallocations scc-uid -o yaml | grep -o "/" | wc -l 16 [ramakasturinarra@dhcp35-60 cucushift]$ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.5.0-0.nightly-2020-08-01-204100 True False 12m Cluster version is 4.5.0-0.nightly-2020-08-01-204100 After 10K project creation: =================================== [ramakasturinarra@dhcp35-60 cucushift]$ oc get projects | wc -l 10099 [ramakasturinarra@dhcp35-60 cucushift]$ oc get projects | grep knarra | wc -l 10042 [ramakasturinarra@dhcp35-60 cucushift]$ oc get rangeallocations scc-uid -o yaml | grep -o "/" | wc -l 2011 After 10K project deletion: ================================= [ramakasturinarra@dhcp35-60 cucushift]$ oc get rangeallocations scc-uid -o yaml | grep -o "/" | wc -l 19 [ramakasturinarra@dhcp35-60 cucushift]$ oc get projects | wc -l 58
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Container Platform 4.5.5 bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:3188