1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
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: -->
|
