While that is a fair assessment of the situations where this pain point arises, there should be a better option for facilitating #3 without allowing #1 or #2 as this is a common problem disrupting both sides of the situation.
Knee jerk thought would be to modify the ProjectRequest API to allow requestor to specify anything the ClusterResourceQuota object can control. This would allow new projects being created to sized right until some situation to support resizing existing projects can be developed. On Thu, Aug 30, 2018 at 2:46 PM Clayton Coleman <ccole...@redhat.com> wrote: > Ultimately you need to ask what you are trying to prevent: > > 1. a user from accidentally blowing up the cluster > 2. malicious users > 3. an application breaking at runtime because it needs more resources than > it is allotted > > The second one is more what we've been discussing here - being draconian > up front. 1 is usually where you'd have two quotas - initial, and > generous, and then just swap them out as needed, possibly via some > automation. 3 is what most people are most afraid of (failing to meet your > SLA because you didn't allocate resources). > > > > > > On Thu, Aug 30, 2018 at 2:17 PM Andrew Feller <afel...@bandwidth.com> > wrote: > >> Thanks for the feedback Jessica! >> >> Limiting # of projects users can create is definitely one of the things >> expected, however the question was mostly focused on reducing toil due to >> changing resource quotas for projects. The idea with option #1 was >> restricting devs to 1 project with heftier resources allocated whereas the >> hope with option #2 was ClusterResourceQuota per developer might relax >> other options for developers to modify project resource quotas without >> waiting on system administrators. >> >> On Thu, Aug 30, 2018 at 10:14 AM Jessica Forrester <jforr...@redhat.com> >> wrote: >> >>> >>> >>> On Thu, Aug 30, 2018 at 8:18 AM Andrew Feller <afel...@bandwidth.com> >>> wrote: >>> >>>> Has anyone found an effective way to minimize toil between developers >>>> and system administrators regarding project resource quotas *without >>>> resorting to letting people do whatever they want unrestrained*? >>>> >>>> There are only 2 ideas I can see to address this issue: >>>> >>>> 1. Removing self-provisioning access, provisioning a single project >>>> per developer, and giving them admin access to it. >>>> >>>> >>> You can limit the number of self-provisioned projects they can have >>> >>> https://docs.openshift.com/container-platform/3.10/admin_guide/managing_projects.html#limit-projects-per-user >>> >>> >>>> >>>> 1. Create ClusterResourceQuota per developer restricting total >>>> resources allowed >>>> >>>> I don't know how ClusterResourceQuota handle a system administrator >>>> increasing a project's quotas for a user who is already met their total. >>>> >>> >>> If either a cluster resource quota or a resource quota has been >>> exceeded, then you you've exceeded quota for that resource and can't make >>> more. >>> >>> >>>> >>>> Any feedback is welcomed and appreciated! >>>> -- >>>> >>>> [image: BandwidthMaroon.png] >>>> >>>> Andy Feller • Sr DevOps Engineer >>>> >>>> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606 >>>> >>>> >>>> e: afel...@bandwidth.com >>>> _______________________________________________ >>>> users mailing list >>>> users@lists.openshift.redhat.com >>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>>> >>> >> >> -- >> >> [image: BandwidthMaroon.png] >> >> Andy Feller • Sr DevOps Engineer >> >> 900 Main Campus Drive, Suite 500, Raleigh, NC 27606 >> >> >> e: afel...@bandwidth.com >> _______________________________________________ >> users mailing list >> users@lists.openshift.redhat.com >> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >> > -- [image: BandwidthMaroon.png] Andy Feller • Sr DevOps Engineer 900 Main Campus Drive, Suite 500, Raleigh, NC 27606 e: afel...@bandwidth.com
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
