cs3org / charts Goto Github PK

When no config.{wopisecret,iopsecret} value is provided when installing the wopiserver chart, a pair of random secrets is generated for convenience.

However, this does also happen across upgrades:

staging, iop-wopiserver-secrets, Secret (v1) has changed:
  # Source: iop/charts/wopiserver/templates/secrets.yaml
  apiVersion: v1
  kind: Secret
  metadata:
    labels:
      app.kubernetes.io/instance: iop
      app.kubernetes.io/managed-by: Helm
      app.kubernetes.io/name: wopiserver
      app.kubernetes.io/version: v5.4
      helm.sh/chart: wopiserver-0.2.0
    name: iop-wopiserver-secrets
  data:
-   iopsecret: '-------- # (24 bytes)'
-   wopisecret: '-------- # (24 bytes)'
+   iopsecret: '++++++++ # (24 bytes)'
+   wopisecret: '++++++++ # (24 bytes)'
  type: Opaque

This behavior is not intended, as might require updating the IOP ConfigMap or reloading the IOP Deployment when using REVA_APPPROVIDER_IOPSECRET.

• Protocol scheme on wopiurl and downloadurl

Makes way more sense to keep each piece's ingress at their own chart for a standalone deployment maintaining all the config options.

Use a sidecar to notify the revad process (or container) when its config changes.

Prometheus also uses SIGHUP to re-read its config and configmap-reload on their chart.

Also, and following the work laid out on #5, target the right container inside the revad pod.

When trying to login to Reva, I'm getting an error:
login basic username: test password: error: code=CODE_INTERNAL msg="error creating user home" support_trace="00000000000000000000000000000000"

I'm running Reva like this:
helm upgrade --install -n default iop-home . --set persistentVolume.enabled=true --set persistentVolume.existingClaim=iop-pvc --set-file configFiles.revad\\.toml=home.toml --set-file configFiles.gateway\\.toml=standalone.toml --set-file configFiles.users\\.json=users-ailleron.json --set env.REVA_APPPROVIDER_IOPSECRET=qwerty12345 --set imagePullSecrets.name=regcred

I tried running storage provider separately:
helm upgrade --install -n default storageprovider-home . --set env.REVA_APPPROVIDER_IOPSECRET=qwerty12345 -f home-sp.yaml

To expose the /metrics endpoint for Prometheus, a [http.services.prometheus] service needs to be added to the IOP config map, e.g. to gateway.toml

Up to now we had https://mesh.pondersource.org/ running with revad listening directly to port 443, using this built-in TLS feature of revad.

But this helm chart doesn't seem to use it. Instead, it seems that we should be using some sort of ingress using the ingress.services.{http,grpc}.tls config that is mentioned in https://github.com/cs3org/charts/tree/master/revad#configuration ?

I'm not very experienced with kubernetes and there is very little "Getting Started" info here.

I see the following sites all run revad with TLS on port 443:

• https://iop.sciencemesh.uni-muenster.de/iop/ocm
• https://sciencemesh.cesnet.cz/iop/ocm
• https://sciencemesh.cernbox.cern.ch/iop/ocm
• https://app.cs3mesh-iop.k8s.surfsara.nl/iop/ocm
• https://surf-iop-rd-app-acc.data.surfsara.nl/ocm
• https://exp-surf-iop-rd-app-acc.data.surfsara.nl/ocm
• https://sciencemesh.cubbit.io/ocm
• https://sciencemesh.softwaremind.com/iop/ocm
• https://sciencemesh-test.switch.ch/iop/ocm
• https://cs3mesh.sciencedata.dk/ocm
• https://mesh.pondersource.org/ocm

How do they do it? Are there no docs about this?

There is a collision of used ports as both reva and gateway containers use
the same gateway.toml

Related: #2