This is in preparation for spinning up a staging/QA matrix instance,
where the MXID domain is under control by hscloud machinery (and not a
top-level organizational domain).
Change-Id: I10505615ebb407b3b2eac0c1b87ad5625e2009c0
This is in prepration for bringing up a Matrix server for hsp.sh.
Verified to cause no diff on prod.
Change-Id: Ied2de210692e3ddfdb1d3f37b12893b214c34b0b
This deploys office.hackerspace.pl. It's a collaborative document
editing server that works with Nextcloud.
This is already live, and can be tested with owncloud.hackerspace.pl
(new -> document).
Change-Id: Ic8055a8a6679e7a0695ebb9e41108074d8f789af
WHITE
WHALE
HOLY
GRAIL
Complex systems are complex. Let me tell you a story about that.
Matrix clients perform their last stage of login by performing a POST to
/_matrix/client/r0/login on the Matrix homeserver they log in to. How
they reach the Homeserver is specified earlier - either by using
discovery via SRV or .well-known, or by the client manually specifying
the Matrix homeserver URL.
Regardless of how they reach this endpoint in the first place, this POST
endpoint, as per the Matrix Client-Server API Specification (r0.6.1),
MAY return a `well_known` key, which MUST contain a `homeserver`
address, pointing to the address of the homeserver which the client
should talk to. If present, the client SHOULD use that instead of
whatever it connected to so far.
Issue the first: the iOS client requires `well_known` in that response,
and doesn't work otherwise. https://github.com/vector-im/element-ios/issues/3448
Issue the second: Synapse will return `well_known` accordingly, but only
if `public_baseurl` is set in its configuration. It is not required to
be set. If not set, it will simply not return this key.
Shrek the third: we never set `public_baseurl` in Synapse, and the first
issue (iOS needing `well_known`) only became a regression in
https://github.com/vector-im/element-ios/issues/2715 . As such, it was
difficult to troubleshoot this issue, and we kept getting on some red
herrings: is it the SSO? Is our server broken? Is the iOS implementation
broken?
But now we know - https://github.com/vector-im/element-ios/issues/2715
seems to be the true culprit.
Change-Id: I913792e31e3c6813d4e51d4befdba720cad3f532
Configuring this one is a bit different from appservice-irc. Notably,
there's no way to give it a registration.yaml to overlay on top of a
config, se we end up using an init container with yq to do that for us.
Also, I had to manually copy the regsitration.yaml in synapse, from
/appservices/telegram-prod/registration.yaml to
/data/appservices/telegram-prod.jsonnet, in order to make it work with
the synapse docker start magic. :/
Otherwise, this is deployed and seems to be working.
Change-Id: Id747a0e310221855556c1d280439376f0c4e5ed6
This is in preparation for adding a Telegram bridge appservice. The main
jsonnet file was getting quite chonky.
This does not affect production, and is just a refactor.
Change-Id: I7cdee2bd71aedb40a9f6c3e5148f829023171dcb
The way this was migrated is not to be spoken of.
(hint: it involved downtime, and mounting two volumes at once)
appservice-irc has some storage, we should migrate that to waw3, too. But
it's not as critical.
The new storage (waw3) is _much_ faster.
Change-Id: I4b4bd32e4fedc514753d25bac35d001e8a9c5f00
When deploying https://gerrit.hackerspace.pl/c/hscloud/+/401 we manually
re-pinned appservice-irc to run on bc01n03 (to prevent reschedule as
bc01n02 was updated while bc01n03 was already done). This change makes
git reflect production.
Change-Id: I2518a8a227bfacefd9f1905ded5a1d65e379845f
This has already been bumped in production, and this change makes it
reflect that.
This was supposed to fix iOS sign-in, but that didn't seem to have
worked.
Change-Id: I9278490e40b332a8439fdf1361f27df770b8cd9e
At some point someone bumped appservice-irc to 0.17.1 without commiting
this to git. This fixes that, and also drive-by refactors the
appservice-irc image version to live next to all the other version
strings.
`kubecfg diff --diff-strategy=subset prod.jsonnet` now shows no diff.
Change-Id: I90a64d05cc72669de41fa68195672adca2eb37e8
Only these nodes (and bc01n03( are #blesed by freenode.
In the future we should fix this by having custom node labels for
blessed nodes. But this will do for now.
Change-Id: Ia5d7cfcb9329da0de8d596ed40b20b0e0f286f43
Some pods got evicted. Some of them broke.
- postgres in matrix and nginx in internet because of the new policies
(chown issues)
- cas proxy in matrix because apparently the image was not reuploaded
to the regsitry after ceph-waw1 died, and another node didn't have it
- registry because it had a weak image pin an downgraded to some
broken version on another node
Change-Id: I836036872629843c8ede1b7f67982112c90d71f0
Dynamic config generation based on environment variables in Synapse is
no longer supported. To pass secrets to container we use a patch that
implements configuration overrides via environment variables directly.
(to be upstreamed...)
Due to Synapse update, appservice configuration ConfigMaps don't need to
be copied into Synapse /data volume anymore.
Change-Id: I70e6480983bfb997362739c6ce0ec3c313320836
This makes a registry be automatically part of the cluster
infrastructure.
Tested by running kubecfg diff, no diffs (apart from out-of-date ACLs)
found.
Change-Id: Ic0635e789cf3fb851f410bcf2865326f1fa87545
We have quite a bit of them at this point, and we're likely going to use
app/* and go/svc/* for 'core' services only anyway.
Change-Id: Ic315fbd2d672e525439992bfcd9ead730d1a1b71
Another change I lost somewhere in the process of remembering how to
gerrit.
I rewrote it (lost the original commit), and also added the (upcoming)
egressifier service.
Change-Id: I1647bc3b1e504a192150ab76f4c6d1709e608f0a
This change impelements the k8s machinery for Gerrit.
This might look somewhat complex at first, but the gist of it is:
- k8s mounts etc, git, cache, db, index as RW PVs
- k8s mounts a configmap containing gerrit.conf into an external
directory
- k8s mounts a secret containing secure.conf into an external directory
- on startup, gerrit's entrypoint will copy over {gerrit,secure}.conf
and start a small updater script that copies over gerrit.conf if
there's any change. This should, in theory, make gerrit reload its
config.
This is already running on production. You're probably looking at this
change through the instance deployed by itself :)
Change-Id: Ida9dff721c17cf4da7fb6ccbb54d2c4024672572
q3k
informatic