Data migration and Migrating from 3.x to 4.x in Kubernetes #1722
Conversation
henokgetachew
requested review from
eljhkrr,
witash,
1yuv,
Hareet,
mrjones-plip and
dianabarsan
There was a problem hiding this comment.
Nice work! We're in strong need of more k8s docs - yay!
I've made some suggestions - since this is endemic to Medic, we should move this to the Medic section so it's a peer of the existing EKS docs
| # Get the PVC name | ||
| kubectl get pvc -n $NAMESPACE | ||
|
|
||
| # Get the volume ID from the PVC | ||
| VOLUME_ID=$(kubectl get pvc <your-3x-pvc-name> -n $NAMESPACE -o jsonpath='{.spec.volumeName}') | ||
| EBS_VOLUME_ID=$(kubectl get pv $VOLUME_ID -o jsonpath='{.spec.awsElasticBlockStore.volumeID}' | cut -d'/' -f4) |
There was a problem hiding this comment.
I think because this section is so long, it's likely having them manually set <your-3x-pvc-name> to be an env var. let's break this out into it's own step to find the the PVC name and set the three env vars. the next larger section can then just by copy and pasted blindly
There was a problem hiding this comment.
I get your point. I also considered doing that. The issue is that there will be more than one pvc and we pretty much want the user to identify the pvc that has the data.
| First verify CouchDB is running properly: | ||
| ```shell | ||
| # Check pod status | ||
| kubectl get pods -n $NAMESPACE | ||
|
|
||
| # For single node check CouchDB is up | ||
| kubectl exec -it -n $NAMESPACE $(kubectl get pod -n $NAMESPACE -l cht.service=couchdb -o name) -- \ | ||
| curl -s http://localhost:5984/_up | ||
|
|
||
| # For clustered setup (check all nodes) | ||
| kubectl exec -it -n $NAMESPACE $(kubectl get pod -n $NAMESPACE -l cht.service=couchdb-1 -o name) -- \ | ||
| curl -s http://localhost:5984/_up | ||
| ``` | ||
|
|
||
| Access the new CouchDB pod based on your deployment type. | ||
|
|
||
| For single node: | ||
| ```shell | ||
| kubectl exec -it -n $NAMESPACE $(kubectl get pod -n $NAMESPACE -l cht.service=couchdb -o name) -- bash | ||
| ``` | ||
|
|
||
| For clustered setup (always use couchdb-1): | ||
| ```shell | ||
| kubectl exec -it -n $NAMESPACE $(kubectl get pod -n $NAMESPACE -l cht.service=couchdb-1 -o name) -- bash | ||
| ``` |
There was a problem hiding this comment.
love how we've set $NAMESPACE so all these command work just copy and paste - nice work!!
Co-authored-by: mrjones <[email protected]>
| # Get the PVC name | ||
| kubectl get pvc -n $NAMESPACE | ||
|
|
||
| # Get the volume ID from the PVC | ||
| VOLUME_ID=$(kubectl get pvc <your-3x-pvc-name> -n $NAMESPACE -o jsonpath='{.spec.volumeName}') | ||
| EBS_VOLUME_ID=$(kubectl get pv $VOLUME_ID -o jsonpath='{.spec.awsElasticBlockStore.volumeID}' | cut -d'/' -f4) |
There was a problem hiding this comment.
I get your point. I also considered doing that. The issue is that there will be more than one pvc and we pretty much want the user to identify the pvc that has the data.
|
|
||
| Pre-index views to minimize downtime: | ||
| ```shell | ||
| ./bin/pre-index-views <desired CHT version> |
There was a problem hiding this comment.
With npm link this would just be pre-index-views 4.2.2
We could use k8s jobs but if we go that route, we need to build automation around it to avoid making the guide a lot more complicated. I have made the changes for using |
There was a problem hiding this comment.
Nice work! Thanks for all the changes.
While I told you to to use native numbers, we loose the linkable subheads and clickable TOC on the right - so I did the work of reverting the changes I requested - only fair!
As well, the YAML file has a LOT of changes that are needed, and unless we call them all out, literally having a list of what you need to change, it's too easy to miss one and then the deployment fails. I listed out every item that needs to be changed - but feel free to update nomenclature if you feel it doesn't make sense.
approving, but please update the 4 sections that literally say Henok what are dev and prod values ;)
thanks again!
There was a problem hiding this comment.
I think my only comment here is to add a partial for the sections that are common between these two PRs. More details here: #1723 (review)
|
@dianabarsan there is actually very little that is shared between the two PRs. This one is strictly from medic-eks hosted CHT 3.x to medic-eks hosted CHT 4.x. The order of the steps might be similar but there is very little that's the same. The other PR however definitely can use a partial as the first steps are identical. |
* Data migration in k8s --------------- Co-authored-by: mrjones-plip <[email protected]>
Description
This guide answers:
License
The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.