Remove old documentation

1 files changed, 0 insertions, 171 deletions

diff --git a/docs/meeting_notes/2024-07-02.rst b/docs/meeting_notes/2024-07-02.rst
deleted file mode 100644
index 4d2ba03..0000000
--- a/docs/meeting_notes/2024-07-02.rst
+++ /dev/null
@@ -1,171 +0,0 @@
-2024-07-02
-==========
-
-.. raw:: html
-
-   <!--
-
-   Useful links
-
-   - Infra open issues: https://github.com/python-discord/infra/issues
-
-   - infra open pull requests: https://github.com/python-discord/infra/pulls
-
-   - *If* any open issue or pull request needs discussion, why was the existing
-     asynchronous logged communication over GitHub insufficient?
-
-   -->
-
-Attendees
----------
-
-Joe and Johannes.
-
-Chris unfortunately died in a fatal train accident and could not attend
-the meeting. This incident will be rectified in the next release,
-“Lovering 2.0: Immortability”.
-
-Bella is out on the streets again. We are waiting for approval from the
-Python Discord admins to run another fundraiser.
-
-Agenda
-------
-
--  **Configuration of renovate** (Joe)
-
-   We are replacing dependabot with renovatebot. Johannes welcomes this
-   decision. Joe says we are looking for automatic deployment from
-   Kubernetes to make sure that any updates are automatically deployed.
-
-   **Conclusion**: Implemented.
-
--  **Resizing Netcup servers** (Joe, Johannes)
-
-   We can probably get rid of turing, assess what else we want to deploy
-   on lovelace, and then ask for a resize.
-
-   **Conclusion**: Create issue to move things off turing, remove it
-   from the inventory, remove it from documentation, power it off, then
-   have Joe ask for server removal.
-
--  **Updating the public statistics page** (Johannes)
-
-   Discussing and showcasing possible alternatives to the current
-   infrastructure powering https://stats.pythondiscord.com via the
-   https://github.com/python-discord/public-stats repository. Johannes
-   presents his current scripts that cuddle RRDTool into loading data
-   out of metricity, Joe says we will discuss with Chris what to do
-   here.
-
-   The likely way going forward will be that *we will open an issue to
-   set it up*, the setup will contain an Ansible role to deploy the
-   cronjob and the script onto lovelace alongside with the ``rrdtool``
-   PostgreSQL user.
-
-   **Conclusion**: Johannes will create an issue and codify the setup in
-   Ansible.
-
--  **New blog powered by Hugo** (Johannes)
-
-   Our current Ghost-powered blog is a tiny bit strange, and the
-   onboarding ramp to contribute articles is large. We want to migrate
-   this to Hugo - Johannes is leading the effort on it. The main work
-   will be building an appropriate theme, as no nicely suitable
-   replacement theme has been found so far. Front-end contributors would
-   be nice for this, although currently everything is still local on my
-   machine.
-
-   Joe mentions that we don’t need to take anything particularly similar
-   to the current Ghost theme, just some vague resemblance would be
-   nice. Most of the recommended Hugo themes would probably work.
-   Johannes will check it out further.
-
-   **Conclusion**: Try the `hugo-casper-two
-   theme <https://github.com/eueung/hugo-casper-two>`__ and report back.
-
--  **Finger server** (Joe, Johannes)
-
-   Joe recently proposed `the deployment of a finger
-   server <https://github.com/python-discord/infra/pull/373>`__. Do we
-   want this and if yes, how are we going to proceed with this? If we do
-   not want any, running the ``pinky`` command locally or via ``ssh``
-   would be a sound idea. We also need to consider whether members will
-   update their files regularly - we may want to incorporate
-   functionality for this into e.g. King Arthur.
-
-   Joe says that we shouldn’t put a lot of development effort into it,
-   it would be simply a novelty thing.
-
-   **Conclusion**: This is a nice cheap win for some fun which should
-   just be a simple Python file (via Twisted’s Finger protocol support
-   or whatever) that connects to LDAP (see Keycloak authentication
-   server) and outputs information. We could possibly integrate this
-   into King Arthur as well, so the querying workflow could look like KA
-   -> fingerd -> LDAP, or people could use finger commands directly.
-
--  **Keycloak authentication server** (Joe)
-
-   Joe mentions that we are deploying a Keycloak server because for some
-   members authenticating via GitHub is cumbersome, for instance because
-   their GitHub account is connected to their employer’s GitHub
-   Enterprise installation. We could hook up a finger server to the LDAP
-   endpoint. Joe also mentions that we might want to set up e-mail
-   forwarding from pydis addresses to users via the user database that
-   will be stored in Keycloak.
-
-   Currently we only have a Keycloak installation that stores items in
-   PostgreSQL. This installation can federate to LDAP - we would simply
-   have to settle on some directory service backend. Joe suggests
-   FreeIPA because he’s familar with it (including the Keycloak
-   integration). The problem is that it doesn’t work on Debian. The
-   alternative proposal, given that we’re saving ~50$/month on Linode,
-   would be spinning up a Rocky VM with FreeIPA on it on Linode (we
-   already have the budget) or ask Netcup for another VM. Ultimately,
-   the system to run FreeIPA would be something CentOS-based. One aspect
-   to consider is networking security: in Linode we could use their
-   private cloud endpoint feature to securely expose the LDAP server to
-   Keycloak and other services in Kubernetes, if we were to run it in
-   Netcup, we would need to use a similar setup to what we currently
-   have with PostgreSQL.
-
-   Any Python Discord user would be managed in LDAP, and Keycloak has
-   the necessary roles to write back into LDAP. Keeping the users in
-   FreeIPA up-to-date would be a somewhat manual procedure. Joe’s plan
-   was to pick up the user’s Discord username and use
-   ``[email protected]`` as their name and do account setup as part of
-   the staff onboarding.
-
-   **Conclusion**: Will wait for Chris to discuss this further, but we
-   simply need to decide where we want to run the LDAP service.
-
--  **Flux CD** (Joe)
-
-   Joe proposes deploying `flux <https://fluxcd.io/>`__ as a way to
-   improve the way we manage our CI/CD. We want the cluster to be able
-   to synchronize its state with the git repository. There are some
-   manifests in the repository currently that are not in sync with the
-   cluster version.
-
-   **Conclusion**: Approved, Joe will create an issue and do it.
-
--  **Polonium** (Chris)
-
-   Question came up regarding why the bot does not write to the database
-   directly. Joe said it’s not perfect to have the bot write to it
-   directly - in metricity it works but it’s not perfect. Chris probably
-   had good reason: separation of intent.
-
-   **Conclusion**: Approved, write to R&D for financing.
-
--  **Rethinking Bella: Suggested measures to gain autonomy** (Chris)
-
-   Chris will present our current plans to biologically re-think and
-   improve Bella’s current architecture by means of
-   hypertrophy-supported capillary enlargements, with the final goal of
-   gaining complete control and ownership over the World Economic Forum
-   by 2026. As Bella is currently on parental leave, we will send him
-   the result of this voting via NNCP.
-
-.. raw:: html
-
-   <!-- vim: set textwidth=80 sw=2 ts=2: -->