-
Notifications
You must be signed in to change notification settings - Fork 500
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor backup #301
refactor backup #301
Conversation
@shuijing198799 PTAL |
The mode parameter is creative :) But maybe it means that backup & restore should be separate charts? I think the operation guide needs mention of using helm namespacing of ad-hoc backup/restore. |
@@ -1,8 +1,8 @@ | |||
{{- if .Values.backup.create }} | |||
{{- if eq .Values.mode "backup" }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you validate the mode? Maybe have {{- if neq .Values.mode "restore" && neq .Values.mode "backup" }} ERROR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that should be added. But I can't find any document about fail
or error
in Helm template.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is a fail
function. Helm says they have Sprig functions. http://masterminds.github.io/sprig/flow_control.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great!
The backup and restore have a lot of parameters in common, and the chart is really simple. Making it two separate charts is unnecessary. |
…tor into refactor-backup
Modified the variables in `values.yaml` and then create restore job using the following command: | ||
|
||
```shell | ||
$ helm install charts/tidb-backup --name=<backup-name> --namespace=${namespace} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think one would likely be running this with -set mode=restore
rather than modifying that in values.yaml.
Then run the following command to create an ad-hoc backup job: | ||
|
||
```shell | ||
$ helm install charts/tidb-backup --name=<backup-name> --namespace=${namespace} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would give an example where the backup name is unique:
helm install charts/tidb-backup --namespace=${namespace} --name=tidb-backup-$(date -u '+%F-%T')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar for the restore below
I agree that backup & restore are very similar. I would only make it two separate charts if we can share almost all the files. This could be done with symlinks. But helm charts also support sub-charts and passing values down (we do that for GCP marketplace), which would be another approach. |
GLTM |
/run-e2e-tests |
1 similar comment
/run-e2e-tests |
…tor into refactor-backup
/run-e2e-tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR refactors ad-hoc backup charts and uses external secrets to do the backup and restore.