| Summary: | Allow users to modify project quotas and limits | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Michael Epley <mepley> |
| Component: | RFE | Assignee: | Michal Fojtik <mfojtik> |
| Status: | CLOSED WONTFIX | QA Contact: | Xiaoli Tian <xtian> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.4.0 | CC: | aos-bugs, cyrille.puget, jokerman, mepley, mfojtik, mmccomas |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-12 11:56:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
A few comments/answers: - For example, the cluster admin could set a maximum quota or limit that the project can be allocated, and users could configure a lower quota or limit; This is doable, but I don't see a lot of value. The same user who doesn't want to consume so many resources can always choose not to consume resources. A high quota isn't stopping them. - User increases to quotas or limits could be granted on a temporary basis; Reclaiming quota is near impossible. The system doesn't know which resources in use are now ok to delete. - User quotas or limits could be pooled across shared projects, or reallocated from one user to another user; https://docs.openshift.com/container-platform/3.3/admin_guide/multiproject_quota.html - User changes to quotas or limits could could require addition along one variable be counteracted by reduction in another (ie. trade CPU for memory); Generally these resources aren't that fungible. - Quotas and limits may be fixed, but users can specify these at project creation time. This removes the control of allocating quota for most use cases if project owners can pick who much quota they get in the first place. - Collected usage metrics could drive a recommendation engine to suggest correct quotas or limits to the user, or suggested reallocation/redistribution to cluster admins. This may not be very general purpose. If a user is sitting at their quota limit for long periods of time, are they low on quota or just right? If another project has tons of extra quota except for a few days of the month, should you take their quota away? Also for most cases, having extra quota you don't use doesn't cause any harm. - Changes could be validated against business rules and be automatically granted on a temporary basis for small increases, or require manual approval for larger increases; Temporary is still difficult, but an increase request mechanism would be reasonable for a lot of use cases. As this stands, I can see opening a request for a increase request mechanism. But the remainder of the asks need more information to make them viable IMO. Perhaps you can give a little more detail about who is playing the role of cluster admin and who are the project owners in these scenarios. I'm interested in the first use case where a cluster admin has set default limitrange. A user would like to use smaller values of memory/cpu limit so that it does not consume all his quota. In that case, the only option for him is to change the default requests/limits in every dc or pod. Is there a solution for a user to apply a limitrange different from the one set by cluster admins? With the introduction of OpenShift 4, Red Hat has delivered or roadmapped a substantial number of features based on feedback by our customers. Many of the enhancements encompass specific RFEs which have been requested, or deliver a comparable solution to a customer problem, rendering an RFE redundant. This bz (RFE) has been identified as a feature request not yet planned or scheduled for an OpenShift release and is being closed. If this feature is still an active request that needs to be tracked, Red Hat Support can assist in filing a request in the new JIRA RFE system, as well as provide you with updates as the RFE progress within our planning processes. Please open a new support case: https://access.redhat.com/support/cases/#/case/new Opening a New Support Case: https://access.redhat.com/support/cases/#/case/new As the new Jira RFE system is not yet public, Red Hat Support can help answer your questions about your RFEs via the same support case system. |
Description of problem: Currently, cluster admins must specify default project quotas and limits, or specify these individually by project. However, this has three main drawbacks: either the quotas and limits are inappropriate (too high or too low), or requires manual intervention of a cluster admin to customize, and lastly, they are not dynamic or flexible to accommodate changing application needs. For example, some users may not want to consume their entire allocation (or otherwise allow those resources to be allocated or planned for other areas). Other users may want to provide tighter limits for certain applications or application types. Or applications may need rebalancing of resources -- more cpu but less ram than the default. Version-Release number of selected component (if applicable): All versions of OCP How reproducible: It is currently a design feature of openshift -- default users cannot modify project quotas or limits, only cluster administrators can. Steps to Reproduce (example): 1. log into openshift cluster as a standard user 2. oc patch resourcequotas/quota -p '{"spec" : { "limits" : { "hard" : [ { "cpu" : "2", "memory" : "3Gi", "pods" : "10", "resourcequotas" : "1", "services" : "10" } ] } } } 3. result is: Error from server: User "mepley" cannot "patch" "resourcequotas" with name "quota" in project "myphp" Actual results: quota patched Expected results: Ideally, users should be able to modify quotas or limits -- possibly with cluster administrator restrictions. Several possible arrangements could be available: - For example, the cluster admin could set a maximum quota or limit that the project can be allocated, and users could configure a lower quota or limit; - User increases to quotas or limits could be granted on a temporary basis; - Changes could be validated against business rules and be automatically granted on a temporary basis for small increases, or requite manual approval for larger increases; - User changes to quotas or limits could could require addition along one variable be counteracted by reduction in another (ie. trade CPU for memory); - User quotas or limits could be pooled across shared projects, or reallocated from one user to another user; - Collected usage metrics could drive a recommender engine to suggest correct quotas or limits to the user, or suggested reallocation/redistribution to cluster admins. - Quotas and limits may be fixed, but users can specify these at project creation time. Additional info: