Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?
Date: Tue, 08 Oct 2019 12:22:50
In Reply to: [gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it? by Michael Palimaka
On Tue, Oct 8, 2019 at 7:57 AM Michael Palimaka <kensington@g.o> wrote:
> > On 10/8/19 7:21 AM, Andreas K. Huettel wrote: > > In any case, since many people *do* rely on it, maybe we should declare it > > official? [+] > > > > And, if that's OK with both of you, move it onto infra hardware? > > > > Happy to sponsor both for the next council meeting agenda. > > > > > > [+] At some point the one remaining whiner doesnt count anymore. > > > > In the past, infra has been understandably hesitant to take on new > services due to staffing issues. > > Additionally, I understand that the current infra design does not easily > allow granular access control, preventing non-infra members from easily > performing maintenance on individual services. > > Has this situation changed? I doubt infra want to take responsibility > for the bot, and I don't fancy the hassle of trying to find people to > poke things on my behalf. >
IMO we should have a few tiers: 1. Absolutely core stuff that infra has to run (authentication, LDAP, maybe some services, etc). 2. Community-run stuff that is FOSS, with public config tracking (minus passwords/etc), and reasonably good docs. 3. Community-run stuff that is the wild west. IMO having a service catalog that includes all of this stuff is beneficial, with clear indications as to which tier each thing is in and who to contact with issues. Depending on #1-2 shouldn't really be a problem. #3 can be a playground for experimentation but shouldn't be something we really depend on for core workflow. To mitigate the risk of #2 we could have exercises to clone services following docs/etc. If anything #2 has the potential to be more reliable than #1 if it gets enough attention (though there is no reason our internal services couldn't also be made easy-to-replicate). I think the issue here is that we don't really have any standards for #2, but it is clear that this particular bot is intended to meet those requirements but doesn't quite do so today. I think this is a compromise that could help us focus our infra resources where they're needed most, with some separation of concerns. Ideally we should also make it possible via single-sign-on technologies to leverage infra's authentication services for stuff in tier 2, and maybe tier 3. Biggest risk is phishing if somebody spoofs a sign-on page. -- Rich