-
Notifications
You must be signed in to change notification settings - Fork 330
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
feat: add enableWindows as helm values for Windows DaemonSet creation #388
feat: add enableWindows as helm values for Windows DaemonSet creation #388
Conversation
|
Welcome @jennwah! |
Hi @jennwah. 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 Once the patch is verified, the new status will be reflected by the 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. |
671d81d
to
187a219
Compare
/cc @mauriciopoppe perhaps you can help with moving this easy feature PR forward from issues #381 . Thank you! |
/cc @mauriciopoppe |
/ok-to-test Please squash your changes into 1 commit |
187a219
to
6c5adcc
Compare
Hi @mauriciopoppe , looks like all the tests have passed, can we get a |
helm/provisioner/values.yaml
Outdated
# | ||
# Indicates if Windows DaemonSet should be created (by default: true) | ||
# | ||
enableWindows: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the default value should be false to make Windows deployment an opt-in, unfortunately the chart was already released so I'd argue this'd be a breaking change.
@msau42 @andyzhangx thoughts? I don't know how many people are relying on the helm chart to install the Windows component, as far as I know it was only Microsoft that's using it, maybe we can make this change in a minor patch (e.g. release 1.1.0 of the helm chart).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like perhaps enabling windows deployment by default makes most sense here, for obvious reasons (not introducing breaking changes etc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@msau42 @andyzhangx @mauriciopoppe What do you think guys? Is this feature necessary, considering there're users asking for disabling windows deployment for its redundancy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I think we can add it however we need to be ok whether it should be enabled by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andyzhangx @msau42 please give your valuable opinions here for this feature addition.
Anything would happen if we don't enableWindows by default? How many users would be affected?
Or maybe perhaps we add the feature to disableWindows. But it is counterintuitive in nature....considering all features in helm values are addition add-ons, rather than removals...
Dilemma here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can make it enableWindows: false
by default but we'd need to bump the Helm Chart to v2 because there might be people who already rely on this manifest being installed by default. The more we wait the harder it's going to make this switch.
@andyzhangx are you installing LVP through the Helm chart?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mauriciopoppe Alright lets change to enableWindows: false
by default. I have changed the necessary and also added into documentation as well.
6c5adcc
to
affb0b5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking better, a few comments:
- We have chart examples in https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/tree/master/helm/examples I think you need to run https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/hack/update-generated.sh as well, please try to create a new commit for the generated changes.
- We also need to bump the version of the chart, this is done in
version: 1.0.0 - This change feat(helm): Added volume support for init containers #386 is also ongoing which will create a conflict in the line above, I believe it's a breaking change so I think we could go for the safe route and bump it to v2
Ran the generated scripts for generated examples and also bumped it to |
bd16966
to
10218da
Compare
We flattened a few values in #393 so please update your copy adding the |
10218da
to
e0dc428
Compare
e0dc428
to
5d28fa8
Compare
5d28fa8
to
384652a
Compare
Thanks a lot for your patience @jennwah! /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jennwah, mauriciopoppe 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 |
What type of PR is this?
/kind feature
What this PR does / why we need it:
feat: add enableWindows as helm values for Windows DaemonSet creation
Add feature for enabling Windows DaemonSet if specified. By default its false.
Which issue(s) this PR fixes:
Fixes #381
Special notes for your reviewer:
Release note: