[Tails-project] Proposal: our own GitLab instance, sysadmin…

このメッセージを削除

このメッセージに返信
著者: intrigeri
日付:  
To: Public mailing list about the Tails project
題目: [Tails-project] Proposal: our own GitLab instance, sysadmin'ed by immerda.ch
Hi,

deadline: end of 2019.

We've been discussing GitLab hosting for a bit more than 3 weeks now,
both here and on some private mailing lists. Thanks a lot to everyone
who contributed to these discussions!

Why now?
========

I think I should now make a concrete proposal.

- While all rounds of discussion have not been equally popular, we've
gathered a fair amount of input and I believe I've now understood
well enough what matters to our community in this respect.
If my assessment is incorrect, then a concrete proposal will help
me realize it.

- The option that seems the best to me, by far, is on the table if,
and only if, we make a decision by the end of the year.

- The goal here is not to rank 6+ options according to 25+ criteria;
it's to pick 1 option that works for us. I think there is one
such option.

Proposal
========

I'm hereby proposing we go with immerda.ch. In short:

- The immerda.ch collective manages the OS, the GitLab installation,
and automated upgrades.

- We have our own GitLab instance.

- We have admin credentials on said GitLab instance.

Would this be good enough for you?
Any specific concerns with this proposal?

Rationale
=========

I'll briefly give the key reasons why I'm making this specific
proposal, instead of any of the other options we have:

- I'm quite confident immerda would meet the criteria that are
waiting for clarification by their submitters (trust, political
affinity, maximum number of sub-projects). So choosing it can save
us some discussion time.

- 0xacab

    - Admins are super busy and their latency can unpredictably
      be anywhere between minutes and many months.
    - The limits set on user registration are problematic for
      a project like ours: I'd rather not reject new contributors
      merely because they happen to use GMail.
    - Unclear whether we can get preserve authorship during the migration.
    - Hard to migrate all our settings elsewhere.


- Self-hosted

    This one is very similar to the immerda option, except our
    sysadmins need to do much more work, both in the next few months
    and then in a recurring manner:


    - Makes our somewhat weak sysadmin team even more
      of a single point of failure than it currently is.
    - Puts lots of pressure on our sysadmins (e.g. need to apply
      security updates very quickly)
    - High recurring costs in terms of labour
    - We would need to speed up deployment of new hardware
      as we haven't the capacity to host GitLab yet.


- Tor:

    - tl;dr: too many unknowns wrt. feasibility and the future
    - immerda is ready while Tor is not (and it's not clear when it
      will be).
    - immerda is happy to host us while we don't know yet for Tor.
    - immerda has been hosting stuff for us for 10 years.
      We know that they're reliable and the communication works great.
    - Might require lots of sysadmin work to isolate our CI
      from the rest of our infrastructure.
    - Unclear whether we can get preserve authorship during the migration.
    - Hard to migrate all our settings elsewhere.


- Salsa

    - Salsa is not designed to host confidential data.
    - We don't have good communication channels with the Salsa admins.
      I did not even dare asking if it would be OK to move our
      stuff there. I'm not super bold socially but still, this
      may give you an idea.
    - I'm not confident Salsa admins will ever want to adapt to our
      needs (or even keep coping with them).
    - We can't preserve authorship during the migration.
    - Requires lots of sysadmin work to isolate our CI
      from the rest of our infrastructure.
    - Hard to migrate all our settings elsewhere.


- GitLab.com

    - Not running FOSS
    - No communication channels and as non-paying customers
      we should not count on it.
    - I would not count on their legal resilience to keep our
      confidential data safe.
    - Requires lots of sysadmin work to isolate our CI
      from the rest of our infrastructure.
    - Hard to migrate all our settings elsewhere.


For details, see the more complete comparison and list of criteria:
https://salsa.debian.org/tails-team/gitlab-migration/wikis/hosting/comparison

Drawbacks
=========

By choosing immerda.ch we lose this:

- SSH access is only via Onion Service initially; immerda would need
to do quite some work to change this but it's possible.

- Compared to self-hosted, we rely on the immerda collective to do
a good job at things like DDoS protection. At the moment they're
doing a better job than we are, but who knows, perhaps at some
point they will become the limiting factor and it'll be a problem.

- Compared to shared hosting, we pay the cost of autonomy: there's
a number of difficult decisions/trade-offs we have to make
ourselves, and live with the consequences.

- We are not collocated with close projects such as Debian or Tor,
which I find a bit sad.

That's a direct consequence of having admin credentials, which
gives us lots of autonomy, the ability to preserve authorship
during the migration from Redmine, and more options to migrate
elsewhere later if we want.

https://salsa.debian.org/tails-team/gitlab-migration/wikis/hosting/comparison#collocated-projects

Cheers,
--
intrigeri