From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 2CFAE138334 for ; Tue, 8 Oct 2019 12:22:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A53E5E08D9; Tue, 8 Oct 2019 12:22:45 +0000 (UTC) Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 504E8E088B for ; Tue, 8 Oct 2019 12:22:45 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id x10so10160284pgi.5 for ; Tue, 08 Oct 2019 05:22:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YfeWxfkBAxYDvC9mIhPfXYWLF4DpKUwoWUXhbSru+Fs=; b=Cc+Az56fTVHw48D7y8WmqXEUqwZ67Czos1sUzCb0eFl5Srj7EZC4Dhlwl8oGlSqvc3 uAJoszF4qUKQyF4yLgNxupzfpxa6gygpU040wGdOVgu4kDuSo65eoN37860EtbDA0x5H EfRpFr+2iMrvXujpB0hvdZ5Il2LqF7vJRgnGeiq57KsIRcMSlGNMAjZqzFlUVuxO5RX4 uzCmc3BgHWggF5a3gVKDyr7qWLt+TM4KzLJHoK2E6GbEZTRVilajZTahKKQEJdWFjrUu 7EkaC/Hb1EtyNfyJbbHioQxRtBagTp4jzukabh30GFQJVE5ifIfVXwepVsyZhgIdI+WH W4EA== X-Gm-Message-State: APjAAAXx2gH4BgCdeCM210iMt82G78CSbQGzzNsXV+ftbyQVrwCz85yG g/DFJnPY20pllh60DTLbyhKhag8ujPihyLJJZAz01y4LLLE= X-Google-Smtp-Source: APXvYqwh2SMTmo/aVOtg+FIw/E9wgeS6MUl2YAxc6SSjdd1+Rxzz0y2JiaYQf/GxACXLVKd3j5GFIZXm98KlnxLhOlc= X-Received: by 2002:a17:90a:b289:: with SMTP id c9mr4403016pjr.1.1570537363626; Tue, 08 Oct 2019 05:22:43 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20190926082842.16d58bdd@gentoo.org> <44e7f975-7844-45c6-4d33-15c688b7a5e0@gentoo.org> <4170258.EnrzZEfU2y@porto> <4e4819ce-84e5-8730-da43-177e1219b45e@gentoo.org> In-Reply-To: <4e4819ce-84e5-8730-da43-177e1219b45e@gentoo.org> From: Rich Freeman Date: Tue, 8 Oct 2019 08:22:32 -0400 Message-ID: Subject: Re: [gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it? To: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: a8848039-dea3-4c43-adb3-f4ae4539a238 X-Archives-Hash: 23f033c59f1c3f0ca29b4173ab1dc357 On Tue, Oct 8, 2019 at 7:57 AM Michael Palimaka 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