ProjectRequestLimit plugin: ignore projects in terminating state #8400
Conversation
|
lgtm, but I'm inclined to hold this for 1.2.x. @csrwng do you think its a severe enough problem to warrant inclusion? |
|
IMHO it's not serious enough to be a blocker, but I'll defer to @abhgupta who owns this area |
|
QE should comment if they want to re-use the same name in their tests (which this wont fix) or if they just want to create a new project with different name. |
|
Creating a project with a different name won't help... it's just a count of projects that you've requested. |
|
I understand that. But the original source BZ was commenting on not being able to create a project again when the policy did not give access, and was not specific on if the new project shared the same name if I recall. |
|
I had a quick offline discussion with @csrwng on this and it seems that the risk for this change is minimal and the benefit to the user experience is potentially big. The case is that the user is deleting their project and then trying to create another one within minutes. This could be when the user has run into some issues with their existing project and have resorted to deleting the project and starting afresh using some template. If they are blocked from creating a new project at this point, it just adds to their frustration and makes for a bad user experience. My vote would be for getting this one in. |
|
So I can do the following:
in rapid succession, and cause the server to blow up with projects, thus defeating the point of projects? You should probably allow only 1 or 2 terminating projects to count. |
|
@smarterclayton That's a good point - makes sense to restrict the number of projects in terminating state. However, mid-long term, wouldn't it also make sense to provide visibility via the console and the CLI to the user for their projects in terminating state? Probably just the project name/state without the ability to drill into the resource details would be good. |
|
the projects list acl should not use anything other than policy... I don't want to special case "access to the project OR your username in an annotation" |
|
@liggitt Agreed - the role binding might be deleted. |
csrwng
force-pushed
the
ignore_terminating_projects
branch
from
c4fbceb to
e85d94e
Compare
csrwng
force-pushed
the
ignore_terminating_projects
branch
from
e85d94e to
5ecea6d
Compare
|
@smarterclayton thx, updated to only allow a maximum of 2 terminating projects to not count towards the total considered for admission. |
|
We could move role deletion to the very end of namespace deletion I think we should only allow 1 terminating project for now in this (make it On Thu, Apr 7, 2016 at 3:08 PM, Abhishek Gupta [email protected]
|
|
2 is fine |
|
@deads2k still lgty ? |
Yes, still lgtm. If @smarterclayton approves. Seems like that @abhgupta will get to pick it up in a point release even if it doesn't make 1.2. |
|
It's approved for 1.2
|
|
Ignore my comment above - clayton beat me to the comment by just 1 second. |
|
[merge] |
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/5543/) (Image: devenv-rhel7_3932) |
|
Evaluated for origin merge up to 5ecea6d |
|
[Test]ing while waiting on the merge queue |
|
Evaluated for origin test up to 5ecea6d |
|
continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/2804/) |
Fixes BZ 1324465