diff options
Diffstat (limited to 'docs/meeting_notes/2024-07-02.rst')
| -rw-r--r-- | docs/meeting_notes/2024-07-02.rst | 171 |
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: --> |