Fixes #1 Changes the semantics slightly since I can't set device-id on initial access token anymore, sets it in the resulting secret rather than the spec see: https://github.com/element-hq/synapse/issues/18678 Also the user set in the secret now has the domain embedded in it as well. still depend on synapse due to a kind of stupid dependency on synapse.api.errors.Codes |
||
|---|---|---|
| .forgejo/workflows | ||
| bots-crd.yaml | ||
| deploy.yaml | ||
| Dockerfile | ||
| example.yaml | ||
| matrix_api.py | ||
| matrixbots_operator.py | ||
| pyproject.toml | ||
| rbac.yaml | ||
| README.md | ||
| test_matrixbots_operator.py | ||
matrixbot-operator
Declaratively deploy your synapse matrix bots & keep track of their creds!
You use kubernetes, know how to use kubernetes and understand the benefits of
declarative deployments? Don't run register_new_matrix_user in a pod & then
forget the password / store the password in bao somewhere, just let this
operator do it for you!
Deploy
oh, you want to use this. Here's a kustomization.yaml that will get you in the right direction:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: matrixbots
resources:
- https://git.devhack.net/m/matrixbots-operator/raw/commit/master/bots-crd.yaml
- https://git.devhack.net/m/matrixbots-operator/raw/commit/master/rbac.yaml
- deploy.yaml
and an example deploy.yaml can be found here: deploy.yaml
prerequisites
- a kuberenetes cluster
- a synapse matrix server
- an admin shared registration key for your synapse server
How to use
You can find an example resource in example.yaml, although how to share your
shared secret is left to the user!
Known issues
Right now we don't really have any error handling for the hooked
request_registration command, the operator might report a failure on
re-creation of exisiting bots (but creds won't be overwritten!)
Also, updating existing MatrixBot resources does nothing right now and might
be confusing to see/do, unsure about marking resources as unmodifiable. don't
do it! Ideally, this operator would be idempotent.
Also doesn't have resource deletion hooks, doesn't derigster a bot on resource deletion. it might delete the associated credential though! since there's a lifetime association. might not be desired though, dunno.