feat: add Helm chart for driver deployment#83
feat: add Helm chart for driver deployment#83fmuyassarov wants to merge 4 commits intokubernetes-sigs:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: fmuyassarov 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 |
9598847 to
3ba52b2
Compare
|
@fmuyassarov Can you add the configurations for livenessProbe and readinessProbe |
Yes sure. |
@AutuSnow added #84 for the install.yaml and soon will add here as well. |
Thanks !! |
d6efb7b to
cbb81c8
Compare
|
Similar health probes as in #84 are added here to the chart. |
|
will review again shortly, thanks for the patience |
|
Thanks. But I would ask don't do it yet, because I'm about to add few more improvements in an hour or two. Will ping you once ready. |
cbb81c8 to
ae5cb15
Compare
@ffromani |
| maintainers: | ||
| - name: johnbelamaric | ||
| url: https://github.com/johnbelamaric | ||
| - name: pohly | ||
| url: https://github.com/pohly | ||
| - name: klueska | ||
| url: https://github.com/klueska | ||
| - name: ffromani | ||
| url: https://github.com/ffromani | ||
| - name: pravk03 | ||
| url: https://github.com/pravk03 |
|
/test pull-dra-driver-cpu-e2e-device-mode-grouped-arm64 |
|
/test pull-dra-driver-cpu-e2e-device-mode-grouped-arm64 |
|
|
||
| image: | ||
| repository: us-central1-docker.pkg.dev/k8s-staging-images/dra-driver-cpu/dra-driver-cpu | ||
| tag: latest |
There was a problem hiding this comment.
Should this be a release version ?
There was a problem hiding this comment.
It can be and it doesn't matter much here because eventually we will publish this chart as an OCI artifact same way as container image and during that release process we will have to patch the version to the same as the release version that we are about to cut. In other words, it will be part of the release process PR that I will submit as follow up once the chart lands on the main.
There was a problem hiding this comment.
or to be exact, with image.tag empty values.yaml, the template falls back to .Chart.AppVersion, so the DaemonSet will use the same release version image.
AutuSnow
left a comment
There was a problem hiding this comment.
Thank you for your patience and contribution. I left a comment
| spec: | ||
| selectors: | ||
| - cel: | ||
| expression: device.driver == "dra.cpu" |
There was a problem hiding this comment.
DeviceClass/dra.cpu is cluster-scoped and shared across any installation. helm uninstall will delete it, breaking other deployments or existing ResourceClaims that reference it.
There was a problem hiding this comment.
It it true that uninstalling the chart will delete shared DeviceClass but how is it different from install.yaml? I mean that it's not a Helm specific problem but rather an inherent characteristic of how this driver works. This is the same behavior as kubectl delete -f install.yaml.
There was a problem hiding this comment.
Agree it mirrors install.yaml behavior. But Helm gives us a tool install.yaml doesn't — helm.sh/resource-policy: keep on the DeviceClass would prevent accidental deletion on helm uninstall while preserving create/upgrade semantics. Worth considering since DeviceClass is cluster-scoped shared state. Not a blocker if you prefer to defer.
There was a problem hiding this comment.
That's interesting, thanks for sharing. I wasn't aware of helm.sh/resource-policy: keep annotation. The only thing I'm unsure about is - once this annotation is set, the resources becomes orphaned (according to this document) and in case of a helm upgrade we won't be to replace the resource (when needed).
Are we okay with that?
| spec: | ||
| selector: | ||
| matchLabels: | ||
| {{- include "dra-driver-cpu.selectorLabels" . | nindent 6 }} |
There was a problem hiding this comment.
install.yaml selector is app: dracpu; this chart uses app.kubernetes.io/{name,instance}. DaemonSet selectors are immutable, so users cannot migrate from install.yaml → Helm in place. Either keep the legacy app: dracpu selector label for compat, or add an explicit migration note (delete+reinstall) to README.
There was a problem hiding this comment.
I may be missing something, but I’m not entirely sure why users would need to migrate from install.yaml to Helm. From our perspective, the installation method shouldn’t impact ongoing usage, and we are not expecting/requiring existing users to migrate and I don't see value in doing so.
Those who originally installed the driver using install.yaml can continue running it as is without any changes. For new installations users can choose between install.yaml and Helm, though Helm would generally be the preferred option. Could you help to clarify your question?
ae5cb15 to
2128016
Compare
Alternative to install.yaml with a Helm chart that exposes driver configuration as values.yaml parameters. Signed-off-by: Feruzjon Muyassarov <feruzjon.muyassarov@est.tech>
Signed-off-by: Feruzjon Muyassarov <feruzjon.muyassarov@est.tech>
Signed-off-by: Feruzjon Muyassarov <feruzjon.muyassarov@est.tech>
Signed-off-by: Feruzjon Muyassarov <feruzjon.muyassarov@est.tech>
2128016 to
288396a
Compare
Add a Helm chart for driver installation. This PR adds:
Follow-up (TODO)
ghcr.io/kubernetes-sigs/dra-driver-cpu/charts/dra-driver-cpu0.0.0-mainfrom main branchNote: currently all the templates (DeamonSet, ServiceAccount, etc are based on the what is available in install.yaml).
Fixes: #72