Formal request to set up a KDE Discourse instance

[Ben Cooksley]

On Sat, Mar 13, 2021 at 3:39 AM Nate Graham <nate at 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 at kde.org
> >     I think doing GitLab stuff first makes sense in terms of usage of
> your
> >     time. On that subject, I notice that both Jonathan and Carl (CC'd)
> have
> >     offered to handle setting up the test Discourse instance, or assist
> >     with
> >     it. Perhaps we can do them in parallel, and accomplish a bit of
> >     Sysadmin
> >     onboarding 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 currently
at capacity)
- The type of server in question (bare metal vs. virtual machine, along
with 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 PII
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
service 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 these machines are incompatible and cannot be used for this.

Looking at our other machines with sufficient resources, many of them have
other issues which limit them here.

Often what we will need to do is rebalance workloads, shifting them around
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
many 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
applications elsewhere however was blocked by compatibility issues
surrounding one of the Ruby applications, which was recently resolved. Once
that had been cleared, we then needed somewhere to move them. As another
machine, Hepta, 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, which 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
possible to minimize downtime. If we were to simply add more machines, then
we would end up with empty donated machines - which is a waste of the
donation, as well as not the best use of eV resources.


>
> > In the meantime, it will be interesting to see how the discussion plays
> > out in the issue as there has been some interesting commentary already.
>
> Seems like the discussion has tapered off with Discourse mostly being
> the preferred choice. Other alternatives brought up there seem to be too
> immature or not projected to fully meet our needs.
>
>
> Nate
>

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20210313/697db97c/attachment.htm>