-
Notifications
You must be signed in to change notification settings - Fork 193
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 helm support for existing Service Accounts #877
feat: add helm support for existing Service Accounts #877
Conversation
Hi @kassarl. 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. |
@@ -25,11 +25,20 @@ image: | |||
pullPolicy: IfNotPresent | |||
|
|||
serviceAccount: | |||
create: true | |||
controller: | |||
create: true # When true, a service account will be created for you. Set to false if you want to use your own. |
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.
that's redundant, could just use serviceAccount.controller.name
instead since it would always be provided either by default value or user.
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 was using this "create" value in each of the templates for creating the SA (e.g. serviceaccount-csi-azuredisk-controller.yaml), since that was how it was previously structured. Should I instead do a check, if the name != default then create the service account?
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.
since there is already serviceAccount.create
and rbac.create
, only need to specify controller.name
, node.name
, snapshotcontroller.name
, if user wants to bring their own serviceAccount, they need to --set serviceAccount.create=false --set rbac.create=false --set serviceAccount.controller.name=x --set serviceAccount.node.name=x --set serviceAccount.snapshotcontroller.name=x
42a176b
to
765ca8a
Compare
@@ -25,11 +25,17 @@ image: | |||
pullPolicy: IfNotPresent | |||
|
|||
serviceAccount: | |||
create: true | |||
create: true # When true, a service account will be created for you. Set to false if you want to use your own. | |||
controller: |
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.
what about set serviceAccount.controller: csi-azuredisk-controller-sa
, serviceAccount.node: csi-azuredisk-node-sa
, etc. ? That would make logic more clear.
765ca8a
to
90973b5
Compare
create: true # When true, a service account will be created for you. Set to false if you want to use your own. | ||
controller: csi-azuredisk-controller-sa # Name of Service Account to be created or used | ||
node: csi-azuredisk-node-sa # Name of Service Account to be created or used | ||
snapshotcontroller: csi-snapshot-controller-sa # Name of Service Account to be created or used |
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.
Since service account creation for the snapshot controller is enabled through snapshot.snapshotController.serviceAccount
, it would be better to group this value with that setting, e.g. snapshot.snapshotController.serviceAccountName
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.
good catch, I think we could remove following settings
snapshotController:
serviceAccount: true
rbac: true
should all depend on
serviceAccount:
create: true
rbac:
create: true
That would make the logic more clear.
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.
OK, I have updated it to reflect the snapshot, controller, and node all depending on serviceAccount.create, and the snapshot rbac depending on rbac.create, and removed these fields from snapshot.snapshotController. I think this is a bit clearer, otherwise I can move the snapshot sa name to snapshot.snasphotController
102f337
to
affca89
Compare
/lgtm |
/retest |
@kassarl: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
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. |
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.
/ok-to-test
5bea008
to
5686939
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.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andyzhangx, kassarl 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:
Allows a user to define an pre-created Service Account in the Helm chart, a feature offered offered by other CSI drivers
Which issue(s) this PR fixes:
Fixes #709
Requirements:
Special notes for your reviewer:
Release note: