-
Notifications
You must be signed in to change notification settings - Fork 760
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
liveness probe may be problematic in upgrade #502
Labels
Comments
I think we should not check liveness by calling the API for harbor-core. |
reasonerjt
added a commit
to reasonerjt/harbor-helm
that referenced
this issue
Sep 15, 2020
Fixes goharbor#502 Signed-off-by: Daniel Jiang <jiangd@vmware.com>
Startup probe seems a good option: I'll add it and it means the chart v1.5.0 can't be deployed on k8s version < 1.16 |
reasonerjt
added a commit
to reasonerjt/harbor-helm
that referenced
this issue
Sep 17, 2020
Fixes goharbor#502 Signed-off-by: Daniel Jiang <jiangd@vmware.com>
reasonerjt
added a commit
to reasonerjt/harbor-helm
that referenced
this issue
Sep 18, 2020
Fixes goharbor#502 Signed-off-by: Daniel Jiang <jiangd@vmware.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the liveness probe of core calls the
ping
api for checking the liveness.https://github.com/goharbor/harbor-helm/blob/master/templates/core/core-dpl.yaml#L38
Although the initial delay is configurable, the core may do migration work before serving the requests and the time is not easy to predict. it's possible that the probe may kill the pod when the migration is in progress, which will cause data in consistency.
We should consider other why for the probe.
The text was updated successfully, but these errors were encountered: