fix(helm): Allow pdb minAvailable to take precedence over default max…

[ParichayDidwania]

What type of PR is this?

/kind bug

What this PR does / why we need it:

Allow minAvailable to take precedence over default maxUnavailable in pdb of cluster-autoscaler helm chart

Which issue(s) this PR fixes:

Fixes #7128

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: ParichayDidwania / name: Parichay (b6452f2, b806889)

[k8s-ci-robot]

Welcome @ParichayDidwania!

It looks like this is your first PR to kubernetes/autoscaler 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/autoscaler has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @ParichayDidwania. Thanks for your PR.

I'm waiting for a kubernetes 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-sigs/prow repository.

[jackfrancis]

I think having an {{- else}} block after {{- if .Values.podDisruptionBudget.minAvailable }} here is simpler and equivalent to a separate {{- if and .Values.podDisruptionBudget.maxUnavailable (not .Values.podDisruptionBudget.minAvailable) }} block.

The way the current values.yaml data structure is implemented is sort of incorrect as a way to represent the podDisruptionBudget interface. See:

• https://kubernetes.io/docs/tasks/run-application/configure-pdb/#specifying-a-poddisruptionbudget

Especially:

You can specify only one of maxUnavailable and minAvailable in a single PodDisruptionBudget.

I think this PR points towards an improvement in the existing solution, but FYI we're in a non-ideal place here, as we're essentially putting it on the users to understand that they're only allowed to use one or the other of the child properties of the podDisruptionBudget values object, and that if they do specify both then minAvailable will be preferred, and maxUnavailable will be ignored. (There isn't a great way to do runtime template error validation in helm AFAIK .)

[jackfrancis]

cc @gjtempleton on that last part above

[ParichayDidwania]

I think this PR points towards an improvement in the existing solution, but FYI we're in a non-ideal place here, as we're essentially putting it on the users to understand that they're only allowed to use one or the other of the child properties of the podDisruptionBudget values object, and that if they do specify both then minAvailable will be preferred, and maxUnavailable will be ignored. (There isn't a great way to do runtime template error validation in helm AFAIK .)

I have generally seen in other helm charts that they usually have the podDisruptionBudget block as empty in values.yaml. By default they set it off, and then allow the users to enter what they want.

Usually, when users enter both maxUnavailable and minAvailable together in such case, it will add both within the template instead of prioritizing one over above. Applying this generated template will then throw the error by kubernetes itself suggesting that only one of the 2 should be available. I think this is the correct way to go about it.

The reason I made it prioritize one of the two (maxUnavailable and minAvailable) and did not touch values.yaml was to ensure that it still works the same way for old users. But if that is not the case, then I can change the PR to make it how it should ideally be.

[jackfrancis]

Yeah, that all makes sense, and 💯 on making this back-compat for users.

Now that I think about it, maybe this is the most correct template solution:

  {{- if .Values.podDisruptionBudget.minAvailable and (not .Values.podDisruptionBudget.maxUnavailable) }}
  minAvailable: {{ .Values.podDisruptionBudget.minAvailable }}
  {{- end }}
  {{- if and .Values.podDisruptionBudget.maxUnavailable (not .Values.podDisruptionBudget.minAvailable) }}
  maxUnavailable: {{ .Values.podDisruptionBudget.maxUnavailable }}
  {{- end }}

If we do the above, if users declare both configuration flavors, it will be ignored by the template. I suppose this is not strictly back-compat, but the current template will not work in such a scenario anyways (I assume it will be rejected by apiserver webhook for the PodDisruptionBudget resource type).

wdyt?

[ParichayDidwania]

Yes, the current template is rejected by the webhook if we declare both flavors. It is also rejected if i just add minAvailable in the override yaml file, because maxUnavailable is included by default in values.yaml.

[ParichayDidwania]

if you do not want {{- fail ... }} statements in code, i can put the check in notes and do the same check in deployment.yaml

[jackfrancis]

I like the fail statement, failing fast is a feature not a bug IMO

[ParichayDidwania]

cool, is there anything else you need apart from rebase, for approval?

[jackfrancis]

nope, I'm good with this, thanks!

[ParichayDidwania]

are you waiting on something else before giving the approval?

[jackfrancis]

/assign

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ParichayDidwania]

/remove-lifecycle stale

[jackfrancis]

/lgtm
/approve

thx @ParichayDidwania (for both this improvement and your patience)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jackfrancis, ParichayDidwania

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:

• charts/OWNERS [jackfrancis]

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