mirror of https://gerrit.hackerspace.pl/hscloud
radex
99ed6a7abb
A convention is introduced to specify the kube.Namespace object in a deployment as a `local ns` instead of an `ns:` or a `namespace:` for these reasons: - non-cluster admins cannot create new namespaces, and we've been moving in the direction of specifying objects that require cluster admin permissions to apply (policies, role bindings) in //cluster/kube/k0 instead of in the app jsonnet - namespace admins CAN delete the namespace, making `kubecfg delete` unexpectedly dangerous (especially if a namespace contains more than just the contents of the file being applied - common with personal namespaces) - `.Contain()` is a common operation, and it shows up in lines that are pretty long, so `ns.Contain()` is preferable to `app.ns.Contain()` or `service.namespace.Contain()` Change-Id: Ie4ea825376dbf6faa175179054f3ee3de2253ae0 Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1804 Reviewed-by: q3k <q3k@hackerspace.pl> |
||
---|---|---|
.. | ||
README.md | ||
prod.jsonnet |
README.md
ONLYOFFICE Document Server
Production running at office.hackerspace.pl.
JWT secret kept in Kubernetes secrets. Can work with any nextcloud instance as long as the JWT secret is configured correctly.
Has a volume for some persistent data - but this is mostly for caching. As far as I (q3k) undestand, these can be nuked with no repercussions, maybe apart from losing in flight edits.
See prod.jsonnet for more information.