Subject: Github partial failure is slowing us down on the day of the I-D deadline

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Oct 2018 17:07:40 +0200

The day of the Internet-Draft deadline is a day where a lot of last-minute coordination happens.
Much of it over github.

Today we have a nice demonstration of the consequences of a single point of failure: https://twitter.com/githubstatus
Yes, this can be worked around, but it does take some extra effort.
Personally, I’m not sure I will get all the drafts done in time for the deadline that I wanted to get done.

Grüße, Carsten

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 22 Oct 2018 16:32:08 -0400

Funny (or maybe not so funny) .... when a Github overview was presented at
the WG chairs session at IETF 102,  I asked if the IETF should be dependent
on resources not under our control and if there was any way to replicate
Github functionality on one of our own servers. The answer given was that
Github is where the developers are, so that's where we should be as well,
and it shouldn't be a problem as Github is now a major industry resource
and dependency, and the new owners would be careful to maintain it as such
...

Cheers,
Andy

On Mon, Oct 22, 2018 at 11:08 AM Carsten Bormann <[email-masked]> wrote:

> Today we have a nice demonstration of the consequences of a single point
> of failure: https://twitter.com/githubstatus

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Oct 2018 22:39:05 +0200

On Oct 22, 2018, at 22:32, Andrew G. Malis <[email-masked]> wrote:
> 
> Funny (or maybe not so funny) .... when a Github overview was presented at the WG chairs session at IETF 102,  I asked if the IETF should be dependent on resources not under our control and if there was any way to replicate Github functionality on one of our own servers. The answer given was that Github is where the developers are, so that’s where we should be as well, and it shouldn't be a problem as Github is now a major industry resource and dependency, and the new owners would be careful to maintain it as such ...

Yes, and that is all true.

What I was pointing out was that the inevitable failures of a resource we heavily rely on now probably require some flexibility in our own timelines.

Note that the need for flexibility has arisen before, when our own infrastructure failed in some way near the I-D deadline.
(Which is actually more likely as our own infrastructure is stressed during this time, while the github partial failure today was a mere coincidence.)

Grüße, Carsten

---

From: Randy Bush <[email-masked]>
Date: Mon, 22 Oct 2018 14:32:34 -0700

> Today we have a nice demonstration of the consequences of a single
> point of failure: https://twitter.com/githubstatus

the community has been moving to centralization for a decade.  results
are inevitable.

roll your own,  https://gogs.io/

randy

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Oct 2018 23:38:36 +0200

> roll your own,  https://gogs.io/

But this means everyone has their own outages.

Centralizing the outages means that the IETF chair gets hit by the outage that hit you, too, and we get an extension.
Sounds better to me from an organizational point of view.

Grüße, Carsten

(Only half joking.)

---

From: Leif Johansson <[email-masked]>
Date: Mon, 22 Oct 2018 23:40:02 +0200

> roll your own,  https://gogs.io/

.. or make github do RFC8484 to make the outages a bit more fulfilling

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 22 Oct 2018 17:41:58 -0400

> But this means everyone has their own outages.
or IETF operates a gogs or gitlab or ...

except you said earlier: "devs are at github, so we must go there"
which means that the IETF accepted this external dependency... which seems
ok.

> Centralizing the outages means that the IETF chair gets hit by the outage
> that hit you, too, and we get an extension.

yea, it seems like you really just want a lever to pull that says: "give me
an extension please because $OUTAGE"
which appears to exist.