Add helm chart#163
Conversation
|
Welcome @honghainguyen777! |
|
Hi @honghainguyen777. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
✅ Deploy Preview for node-readiness-controller canceled.
|
eb0d1d7 to
9035670
Compare
There was a problem hiding this comment.
Thanks for working on this chart. I tested the PR locally from the fetched review-pr-163 branch
Commands/results:
helm lint charts/nrr-controllerpassedhelm template test charts/nrr-controller --namespace node-readiness-systemrendered successfullyhelm template test charts/nrr-controller --namespace node-readiness-system --set webhook.enabled=true --set validatingWebhook.enabled=true --set certManager.enabled=truerendered successfullyhelm package ./charts/nrr-controller --dependency-update --destination /tmp/nrr-chart-packagepassed- Installed into a 3-node kind cluster using the PR’s
make kind-multi-node helm install nrr-test charts/nrr-controller --namespace node-readiness-system --create-namespace --wait --timeout 2msucceeded- Controller pod became Ready, the CRD was installed, and a sample
NodeReadinessRulecreated through chart values reconciled successfully across all 3 kind nodes
I also installed the same Helm unittest plugin version used by the workflow and ran:
helm unittest charts/nrr-controller --strict
That currently fails with 4 failing tests:

so the rendered Deployment contains annotations by default
the plugin reports these as expect ... to be an array. These assertions likely need to use equal or target the parent arrays instead
Cc @ajaysundark
|
Hi @sahitya-chandra, thanks a lot for the detailed testing and feedback! I’d actually love to get more contributors involved with the chart so we can maintain it well going forward, so a follow-up fix from you would be more than welcome :) |
|
/assign @ajaysundark for the final review |
|
/ok-to-test |
|
pushing the unittest fix in a bit |
|
/retest |
|
Oh, I forgot that I don't have permissions to directly push to this branch, pushed to my fork instead, @honghainguyen777 can cherry-pick this f9b0a6a or I can raise a pr once this pr gets merged |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: honghainguyen777 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@sahitya-chandra I have cherry-picked your commit. Thank you very much! <3 |
|
@sahitya-chandra could you take a second look before @ajaysundark does the final review? |
|
Re-reviewed, No blocking issues from my side, looks good |
|
/lgtm since @sahitya-chandra who is more familiar with the project than me has reviewed it twice |
| @@ -0,0 +1,17 @@ | |||
| #!/usr/bin/env bash | |||
There was a problem hiding this comment.
Can we also add a hack/verify-chart-drift.sh and wire it into both hack/verify-all.sh and .github/workflows/helm.yaml. It doesnt have to be exhaustive check, maybe a simple diff check to match controller-gen output to chart?
There was a problem hiding this comment.
Added hack/verify-chart-drift.sh and wired it into both hack/verify-all.sh and .github/workflows/helm.yaml. The check runs make manifests and diffs the controller-gen CRD against the chart CRD.
| port: 8443 | ||
| targetPort: 9443 |
There was a problem hiding this comment.
Note: this conflicts with current upstream config/webhook/service.yaml that uses 443 -> 9443. This is why we should have guardrails to maintain configuration consistency between helm and kustomize artifacts.
There was a problem hiding this comment.
Fixed. The chart default now matches upstream config/webhook/service.yaml: 443 -> 9443.
|
New changes are detected. LGTM label has been removed. |
711cd53 to
68e3085
Compare
68e3085 to
9667275
Compare
| | `fullnameOverride` | String to fully override `nrr-controller.fullname` template | `""` | | ||
| | `namespaceOverride` | Override the deployment namespace; defaults to .Release.Namespace | `""` | | ||
| | `replicaCount` | The replica count for Deployment | `1` | | ||
| | `leaderElection.enabled` | Enable leader election to support multiple replicas | `false` | |
There was a problem hiding this comment.
leaderElection default should be true!
There was a problem hiding this comment.
Fixed. The chart now defaults leaderElection.enabled to true!
|
|
||
| # helm-extra-set-args only available after ct 3.6.0 | ||
| - name: Run chart-testing (install) | ||
| run: ct install --config=.github/ci/ct.yaml --helm-extra-set-args='--set=kind=Deployment' |
There was a problem hiding this comment.
how is this extra-args used? I dont see it in ct.yaml?
There was a problem hiding this comment.
Good catch. That was leftover when I did some tests. I removed the extra chart-testing install arg.


Description
Add a Helm chart for deploying the node-readiness-controller.
This chart installs the node-readiness-controller along with the required
Kubernetes resources, including:
values.yamlThe chart follows conventions used by existing charts in https://github.com/kubernetes-sigs
(e.g. descheduler) and supports customization via Helm values.
Relationship to #128
This PR overlaps with #128 (
feat: provision helm chart). I missed that existing PR when opening this one. Depending on maintainer preference, this PR can either supersede #128 or be reconciled with it so we land a single Helm chart implementation.Related Issue
None
Type of Change
/kind feature
Testing
The chart was tested locally using Helm:
Verified:
NodeReadinessRuleresources render correctly when defined invalues.yamlhelm templateChecklist
make testpassesmake lintpassesmake lint-chartpassesmake build-helmpassesmake ct-helmpassesDoes this PR introduce a user-facing change?