Yeah, we have heterogenous trust levels between production and non-production environments. This discussion was focused solely on non-production environment where project default template is minimal footprint and system administrators are in line for increasing project resource quotes per developer per project. Since some projects require more resources than others, we want to prevent non-administrators from blowing up the cluster with wasteful resource usage but not so confined they need someone holding their hands on a regular basis.
On Tue, Sep 4, 2018 at 8:54 AM Clayton Coleman <ccole...@redhat.com> wrote: > > > On Sep 4, 2018, at 8:30 AM, Andrew Feller <afel...@bandwidth.com> wrote: > > 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. > > > If you trust your developers to resize, create a role that you bind to the > namespace / account when you trust them. Or just add it to edit and they’d > have it by default. > > The complicated scenarios are usually when your trust domains are > heterogeneous - it didn’t sound like that was your case. > > > 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 > > -- [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
