On Tue, Oct 8, 2019 at 7:57 AM Michael Palimaka <kensing...@gentoo.org> 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

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.


Reply via email to