There are a lot of possible ways to automate or improve this. Part of the reason we have hesitated to add more complexity was because of the divergence of use cases.
It usually boils down to asking “who” or “why”. One option for empowering specific trusted individuals is to write a quick loop to identify when someone is given access to a project, or just do it via their membership in a group. I’ve seen a few people build things like this, but by design most of them are very simple and use case driven. > On Sep 4, 2018, at 12:37 PM, Walters, Todd <todd_walt...@unigroup.com> wrote: > > This is a similar option we’d like to have a solution to. We have ‘tech > leads’ for projects that are in openshift role that can provision projects. > These are typically done via Jenkins job. It would be nice to be able to > apply custom project template for each project type so that smaller project > may have small project template with smaller quota and could have med and > large quotas. > > Currently we deploy the default project that has quota/limits set. If an lead > or team need additional resources they submit request to my team to adjust. > > Thanks, > Todd > > > Today's Topics: > > 1. Re: Reducing toil in resource quota bumping (Andrew Feller) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 4 Sep 2018 09:08:41 -0400 > From: Andrew Feller <afel...@bandwidth.com> > To: users@lists.openshift.redhat.com > Subject: Re: Reducing toil in resource quota bumping > Message-ID: > <caag6kngel-_p8q4dh3yg-gzg7epxm3hsssu26v+6yysvjzl...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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. > > > > ######################################################################## > The information contained in this message, and any attachments thereto, > is intended solely for the use of the addressee(s) and may contain > confidential and/or privileged material. Any review, retransmission, > dissemination, copying, or other use of the transmitted information is > prohibited. If you received this in error, please contact the sender > and delete the material from any computer. UNIGROUP.COM > ######################################################################## > _______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
