[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: Formal request to set up a KDE Discourse instance
From:       Carl Schwan <carl () carlschwan ! eu>
Date:       2021-03-12 20:44:09
Message-ID: dnUF8NSRFuxdM1ze-XJQfzMu1cAb8YL-CgmX5izMJ5136vp0iMX8Q9wNQxImz_grqoEoobT6QiEkEOoH-VicP24GiDjzCl7R98EGM7bHcbA= () carlschwan ! eu
[Download RAW message or body]

Le vendredi, mars 12, 2021 7:49 PM, Ben Cooksley <bcooksley@kde.org> a =
=C3=A9crit=C2=A0:

> On Sat, Mar 13, 2021 at 3:39 AM Nate Graham <nate@kde.org> wrote:
>
> > On 3/8/21 1:55 AM, Ben Cooksley wrote:
> > > On Mon, Mar 8, 2021 at 2:55 AM Nate Graham <nate@kde.org
> > >=C2=A0 =C2=A0 =C2=A0I think doing GitLab stuff first makes sense in te=
rms of usage of your
> > >=C2=A0 =C2=A0 =C2=A0time. On that subject, I notice that both Jonathan=
 and Carl (CC'd) have
> > >=C2=A0 =C2=A0 =C2=A0offered to handle setting up the test Discourse in=
stance, or assist
> > >=C2=A0 =C2=A0 =C2=A0with
> > >=C2=A0 =C2=A0 =C2=A0it. Perhaps we can do them in parallel, and accomp=
lish a bit of
> > >=C2=A0 =C2=A0 =C2=A0Sysadmin
> > >=C2=A0 =C2=A0 =C2=A0onboarding too. :) What do you think?
> > >
> > >
> > > We'll need to investigate the capacity and capability of our servers
> > > first to choose one that can potentially handle this (which as noted
> > > earlier, is substantially constrained by the demand of the Discourse
> > > developers to use Docker).
> >
> > Is that something that can only be done by you, or is anyone else
> > available for it? Might this be a good onboarding opportunity?
>
> I'm afraid this is a task that can only be done by the existing members, =
as it requires broad overview of a number of bits of information including:
> - The current load base of our systems (ie. whether the system is current=
ly at capacity)
> - The type of server in question (bare metal vs. virtual machine, along w=
ith the type of the underlying hardware - HDD vs. NVMe SSD for instance)
> - The nature of other workloads on the machine (both in terms of security=
, as well as the load they generate as part of operating)
> - The geographic location of the server in question (as we can't locate P=
II outside of the EU)
>
> To use an example, all of the physical machines we rent from Hetzner are =
deployed using LXC, and all run multiple workloads. As such, any new servic=
e deployed on one of these servers must be both compatible with deployment =
inside an LXC container, as well as compatible with the workloads on those =
machines. As the Discourse developers demand the use of Docker, all of thes=
e machines are incompatible and cannot be used for this.
>
> Looking at our other machines with sufficient resources, many of them hav=
e other issues which limit them here.
>
> Often what we will need to do is rebalance workloads, shifting them aroun=
d to different servers in order to resolve the problem, which does mean it =
can take longer than people would prefer to get things done. This is why ma=
ny of the issues I noted in my earlier email have dependencies between them=
.
>
> To use a recent example here, we've wanted for some time to shutdown Mimi=
 - which hosted our Python and Ruby web applications. The move of these app=
lications elsewhere however was blocked by compatibility issues surrounding=
 one of the Ruby applications, which was recently resolved. Once that had b=
een cleared, we then needed somewhere to move them. As another machine, Hep=
ta, was only hosting WebSVN (which took most of it's disk space, preventing=
 it from hosting anything else immediately) we opted to move WebSVN to one =
of our US based servers (which due to being US based can't handle PII, whic=
h our Ruby/Python apps have to be able to handle). Following that, we were =
able to then move the Ruby/Python applications to Hepta.
>
> It also isn't as simple as just adding more server resources, as in some =
cases the place something will be moving from is a donated machine, and we =
prefer to ensure these are well utilised - meaning something needs to move =
back there in response. We also prefer to move services as little as possib=
le to minimize downtime. If we were to simply add more machines, then we wo=
uld end up with empty donated machines - which is a waste of the donation, =
as well as not the best use of eV resources.

I'm not sure I fully understand your last point. If we add a new machine fo=
r
a new service this shouldn't create an empty donated machine. I'm not reall=
y
an expert in things related to sysadmins but looking at the price at for VP=
S
in Hetzner that should be able to handle a service similar to krita-artists=
.org
in term of storage shouldn't cost the e.V. more than =E2=82=AC15 a month. I=
 think the
e.V. can afford that to provide a lively place for the community to ask
questions and discuss things related to KDE.

Cheers,
Carl


>
> > > In the meantime, it will be interesting to see how the discussion pla=
ys
> > > out in the issue as there has been some interesting commentary alread=
y.
> >
> > Seems like the discussion has tapered off with Discourse mostly being
> > the preferred choice. Other alternatives brought up there seem to be to=
o
> > immature or not projected to fully meet our needs.
> >
> > Nate
>
> Cheers,
> Ben
[prev in list] [next in list] [prev in thread] [next in thread]