1 files changed, 171 insertions, 0 deletions
diff --git a/docs/meeting_notes/2024-07-02.rst b/docs/meeting_notes/2024-07-02.rst
new file mode 100644
index 0000000..029d53e
--- /dev/null
+++ b/docs/meeting_notes/2024-07-02.rst
@@ -0,0 +1,171 @@
+DevOps Meeting Notes
+====================
+
+.. 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: -->