| 1 |
On Tue, Oct 8, 2019 at 7:57 AM Michael Palimaka <kensington@g.o> wrote: |
| 2 |
> |
| 3 |
> On 10/8/19 7:21 AM, Andreas K. Huettel wrote: |
| 4 |
> > In any case, since many people *do* rely on it, maybe we should declare it |
| 5 |
> > official? [+] |
| 6 |
> > |
| 7 |
> > And, if that's OK with both of you, move it onto infra hardware? |
| 8 |
> > |
| 9 |
> > Happy to sponsor both for the next council meeting agenda. |
| 10 |
> > |
| 11 |
> > |
| 12 |
> > [+] At some point the one remaining whiner doesnt count anymore. |
| 13 |
> > |
| 14 |
> |
| 15 |
> In the past, infra has been understandably hesitant to take on new |
| 16 |
> services due to staffing issues. |
| 17 |
> |
| 18 |
> Additionally, I understand that the current infra design does not easily |
| 19 |
> allow granular access control, preventing non-infra members from easily |
| 20 |
> performing maintenance on individual services. |
| 21 |
> |
| 22 |
> Has this situation changed? I doubt infra want to take responsibility |
| 23 |
> for the bot, and I don't fancy the hassle of trying to find people to |
| 24 |
> poke things on my behalf. |
| 25 |
> |
| 26 |
|
| 27 |
IMO we should have a few tiers: |
| 28 |
|
| 29 |
1. Absolutely core stuff that infra has to run (authentication, LDAP, |
| 30 |
maybe some services, etc). |
| 31 |
2. Community-run stuff that is FOSS, with public config tracking |
| 32 |
(minus passwords/etc), and reasonably good docs. |
| 33 |
3. Community-run stuff that is the wild west. |
| 34 |
|
| 35 |
IMO having a service catalog that includes all of this stuff is |
| 36 |
beneficial, with clear indications as to which tier each thing is in |
| 37 |
and who to contact with issues. |
| 38 |
|
| 39 |
Depending on #1-2 shouldn't really be a problem. #3 can be a |
| 40 |
playground for experimentation but shouldn't be something we really |
| 41 |
depend on for core workflow. To mitigate the risk of #2 we could have |
| 42 |
exercises to clone services following docs/etc. If anything #2 has |
| 43 |
the potential to be more reliable than #1 if it gets enough attention |
| 44 |
(though there is no reason our internal services couldn't also be made |
| 45 |
easy-to-replicate). |
| 46 |
|
| 47 |
I think the issue here is that we don't really have any standards for |
| 48 |
#2, but it is clear that this particular bot is intended to meet those |
| 49 |
requirements but doesn't quite do so today. |
| 50 |
|
| 51 |
I think this is a compromise that could help us focus our infra |
| 52 |
resources where they're needed most, with some separation of concerns. |
| 53 |
Ideally we should also make it possible via single-sign-on |
| 54 |
technologies to leverage infra's authentication services for stuff in |
| 55 |
tier 2, and maybe tier 3. Biggest risk is phishing if somebody spoofs |
| 56 |
a sign-on page. |
| 57 |
|
| 58 |
-- |
| 59 |
Rich |
Archives