Skip to content
This repository has been archived by the owner on Feb 22, 2022. It is now read-only.

[incubator/vault] Add ability to configure liveness/readiness probe thresholds #23282

Merged
merged 1 commit into from
Jul 24, 2020
Merged

[incubator/vault] Add ability to configure liveness/readiness probe thresholds #23282

merged 1 commit into from
Jul 24, 2020

Conversation

haad
Copy link
Contributor

@haad haad commented Jul 21, 2020

What this PR does / why we need it:

Add ability to configure liveness/readiness probe thresholds and improves missing documentation.

Special notes for your reviewer:

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

  • [ x] DCO signed
  • [ x] Chart Version bumped
  • [ x] Variables are documented in the README.md
  • [ x] Title of the PR starts with chart name (e.g. [stable/mychartname])

@maso7 @haad
[incubator/vault] Add ability to configure liveness/readiness probe t…
c1f19bd 
…resholds.

Signed-off-by: Adam Hamsik <adam.hamsik@lablabs.io>
@helm-bot helm-bot added Contribution Allowed If the contributor has signed the DCO or the CNCF CLA (prior to the move to a DCO). size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jul 21, 2020
@k8s-ci-robot
Copy link
Contributor

Hi @haad. Thanks for your PR.

I'm waiting for a helm member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@k8s-ci-robot k8s-ci-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Jul 21, 2020
jbialy
jbialy reviewed Jul 23, 2020
View reviewed changes
incubator/vault/templates/deployment.yaml
Comment on lines +135 to +137
failureThreshold: {{ .Values.vault.readiness.failureThreshold }}
successThreshold: {{ .Values.vault.readiness.successThreshold }}
timeoutSeconds: {{ .Values.vault.readiness.timeoutSeconds }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about making these values the default unless overridden?

Suggested change
failureThreshold: {{ .Values.vault.readiness.failureThreshold }}
successThreshold: {{ .Values.vault.readiness.successThreshold }}
timeoutSeconds: {{ .Values.vault.readiness.timeoutSeconds }}
failureThreshold: {{ .Values.vault.readiness.failureThreshold | default 3 }}
successThreshold: {{ .Values.vault.readiness.successThreshold | default 1 }}
timeoutSeconds: {{ .Values.vault.readiness.timeoutSeconds | default 1 }}

This way we only have to set these in the values.yaml when needed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize that vault.readiness.initialDelaySeconds and vault.readiness.periodSeconds` should also follow the same convention and currently they don't! 😄

Same goes for the liveness thresholds!

jbialy
jbialy reviewed Jul 23, 2020
View reviewed changes
incubator/vault/templates/deployment.yaml
Comment on lines +121 to +123
failureThreshold: {{ .Values.vault.liveness.failureThreshold }}
successThreshold: {{ .Values.vault.liveness.successThreshold }}
timeoutSeconds: {{ .Values.vault.liveness.timeoutSeconds }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly to the below:

Suggested change
failureThreshold: {{ .Values.vault.liveness.failureThreshold }}
successThreshold: {{ .Values.vault.liveness.successThreshold }}
timeoutSeconds: {{ .Values.vault.liveness.timeoutSeconds }}
failureThreshold: {{ .Values.vault.liveness.failureThreshold | default 3 }}
successThreshold: {{ .Values.vault.liveness.successThreshold | default 1 }}
timeoutSeconds: {{ .Values.vault.liveness.timeoutSeconds | default 1 }}

jbialy
jbialy reviewed Jul 23, 2020
View reviewed changes
incubator/vault/values.yaml
Comment on lines +241 to +243
failureThreshold: 3
successThreshold: 1
timeoutSeconds: 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These can now be removed 🤷

Suggested change
failureThreshold: 3
successThreshold: 1
timeoutSeconds: 1

jbialy
jbialy reviewed Jul 23, 2020
View reviewed changes
incubator/vault/values.yaml
Comment on lines +250 to +253
failureThreshold: 3
successThreshold: 1
timeoutSeconds: 1

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
failureThreshold: 3
successThreshold: 1
timeoutSeconds: 1

@jbialy
Copy link
Contributor

jbialy commented Jul 23, 2020

Hi @haad , thanks so much for the PR! Just a small suggestion. Please let me know what you think and if it makes sense. 😄

@haad
Copy link
Contributor Author

haad commented Jul 24, 2020

IMO I don't like default variables in templates as then I have to search for them in 2 places instead of one (default values). If we don't want to keep them in default values file I can make them optional.

@jbialy
Copy link
Contributor

jbialy commented Jul 24, 2020

IMO I don't like default variables in templates as then I have to search for them in 2 places instead of one (default values). If we don't want to keep them in default values file I can make them optional.

I see your point. Agree. Let's go ahead and leave the new thresholds the way they are, defined in the default values! 👍

@jbialy
Copy link
Contributor

jbialy commented Jul 24, 2020

/ok-to-test

@k8s-ci-robot k8s-ci-robot added ok-to-test and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jul 24, 2020
@jbialy
Copy link
Contributor

jbialy commented Jul 24, 2020

/approve
/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 24, 2020
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: haad, jbialy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 24, 2020
@k8s-ci-robot k8s-ci-robot merged commit cc9d39c into helm:master Jul 24, 2020
li-adrienloiseau pushed a commit to li-adrienloiseau/charts that referenced this pull request Jul 29, 2020
@haad @maso7 @li-adrienloiseau
[incubator/vault] Add ability to configure liveness/readiness probe t…
9d62839 
…resholds. (helm#23282)

Signed-off-by: Adam Hamsik <adam.hamsik@lablabs.io>

Co-authored-by: Marian Soltys <msoltys@pixelfederation.com>
Signed-off-by: Adrien Loiseau <adrien.loiseau@logic-immo.com>
mmingorance-dh pushed a commit to mmingorance-dh/charts that referenced this pull request Aug 28, 2020
@haad @maso7
[incubator/vault] Add ability to configure liveness/readiness probe t…
fb67776 
…resholds. (helm#23282)

Signed-off-by: Adam Hamsik <adam.hamsik@lablabs.io>

Co-authored-by: Marian Soltys <msoltys@pixelfederation.com>
Signed-off-by: Miguel Mingorance <miguel.mingorance@deliveryhero.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@jbialy jbialy jbialy left review comments

@scottrigby scottrigby Awaiting requested review from scottrigby

Assignees
No one assigned
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. Contribution Allowed If the contributor has signed the DCO or the CNCF CLA (prior to the move to a DCO). lgtm Indicates that a PR is ready to be merged. ok-to-test size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@haad @k8s-ci-robot @jbialy @helm-bot @maso7