diff options
| author | 2024-07-02 20:58:16 +0200 | |
|---|---|---|
| committer | 2024-07-07 17:45:35 +0200 | |
| commit | 80a4dd9c511c27736c7af791267ff9e12dc59245 (patch) | |
| tree | b81e7da86c6061c6c216607bf8e71ea4de55dcc5 /docs | |
| parent | Update meeting doc to correct date (diff) | |
Finish meeting notes for today
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/content/docs/meeting_notes/2024-07-02.md | 98 | 
1 files changed, 95 insertions, 3 deletions
| diff --git a/docs/content/docs/meeting_notes/2024-07-02.md b/docs/content/docs/meeting_notes/2024-07-02.md index 5246f16..d84e2c2 100644 --- a/docs/content/docs/meeting_notes/2024-07-02.md +++ b/docs/content/docs/meeting_notes/2024-07-02.md @@ -18,16 +18,49 @@ Useful links  --> +## 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. +  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) @@ -38,6 +71,14 @@ Useful links    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 @@ -47,13 +88,65 @@ Useful links    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 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 @@ -63,5 +156,4 @@ Useful links    leave, we will send him the result of this voting via NNCP. -  <!-- vim: set textwidth=80 sw=2 ts=2: --> | 
