fix(#9468): use latest helm-charts and troubleshooting for volumes

[henokgetachew]

Description

This needs to be merged after this PR gets merged that releases the newest helm-charts.

You use this troubleshooting script to get the pv, pvc information and the subPath you need to set for your pre-existing data.

Example output:

./troubleshooting/get-volume-binding example-namespace cht-couchdb
{
  "mountPath": "/opt/couchdb/data",
  "name": "couchdb-claim0",
  "subPath": "data",
  "volumeType": "PVC",
  "claimName": "couchdb-claim0",
  "hostPath": null,
  "pvName": "couchdb-pv-example-namespace",
  "pvSize": "100Gi",
  "storageClass": null,
  "pvAccessModes": [
    "ReadWriteOnce"
  ]
}

Code review checklist

• Readable: Concise, well named, follows the style guide, documented if necessary.

Compose URLs

If Build CI hasn't passed, these may 404:

• Core
• CouchDB Single
• CouchDB Cluster

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

[mrjones-plip]

While I lightly understand what's going on here, I'm not in a position to competently review this PR.

[mrjones-plip]

@henokgetachew - I'm back! I read too quickly and pretty fully understand this PR now - sorry for pushing back earlier - but didn't want to block you.

I'm not sure what this solves though? I followed these steps and then, being sure I was on the cht-deploy-troubleshooting-and-helm-chart-update branch, ran the new troubleshooting script. Is mountPath supposed to show something more? It got back /opt/couchdb/data just like you did above:

➜  deploy git:(cht-deploy-troubleshooting-and-helm-chart-update) ✗ ./cht-deploy -f mrjones-muso.yml 
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "medic" chart repository
Update Complete. ⎈Happy Helming!⎈
Error from server (NotFound): namespaces "mrjones-dev" not found
Release does not exist. Performing install.
NAME: mrjones-dev
LAST DEPLOYED: Wed Sep 25 17:10:04 2024
NAMESPACE: mrjones-dev
STATUS: deployed
REVISION: 1
TEST SUITE: None
Instance installed successfully: https://mrjones.dev.medicmobile.org

➜  deploy git:(cht-deploy-troubleshooting-and-helm-chart-update) ✗ ./troubleshooting/list-deployments mrjones-dev
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
cht-api                   1/1     1            1           56s
cht-couchdb               0/1     1            0           56s
cht-haproxy               1/1     1            1           56s
cht-haproxy-healthcheck   1/1     1            1           56s
cht-sentinel              1/1     1            1           56s
upgrade-service           1/1     1            1           56s

➜  deploy git:(cht-deploy-troubleshooting-and-helm-chart-update) ✗ ./troubleshooting/get-volume-binding 
Usage: ./troubleshooting/get-volume-binding <namespace> <deployment>


➜  deploy git:(cht-deploy-troubleshooting-and-helm-chart-update) ✗ ./troubleshooting/get-volume-binding mrjones-dev cht-couchdb
{
  "mountPath": "/opt/couchdb/data",
  "name": "couchdb-claim0",
  "subPath": "data",
  "volumeType": "PVC",
  "claimName": "couchdb-claim0",
  "hostPath": null,
  "pvName": "couchdb-pv-mrjones-dev",
  "pvSize": "900Gi",
  "storageClass": null,
  "pvAccessModes": [
    "ReadWriteOnce"
  ]
}

[1yuv]

Left minor suggestion, otherwise code looks good to me.

[henokgetachew]

I'm not sure what this solves though? I followed these steps and then, being sure I was on >the cht-deploy-troubleshooting-and-helm-chart-update branch, ran the new troubleshooting script.

@mrjones-plip, you actually need to run this against the original deployment you want to clone. You then get the subPath from there and plug it into your values.yaml to the dataPathForCouchDBOnDisk key. Then you deploy your new instance.

Not sure how this solves the issue

Given subPath is different based on where your pre-existing data comes from, this troubleshooting script gives you what you need to set it to when deploying a clone with that pre-existing data.

[henokgetachew]

I have made a commit suggestion on the docs PR.

[mrjones-plip]

ok! this makes a LOT more sense now - thank you! I was able to run it on production cluster and see some expected deltas in the subPath

let's get this PR merged and we can focus on the docs PR. Speaking of which - thanks for you addition there - exactly what I was hoping for \o/