-
Notifications
You must be signed in to change notification settings - Fork 38.9k
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
plumb service account token down to csi driver #93130
Conversation
Hi @zshihang. 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 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. |
/assign @msau42 @liggitt @mikedanese |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
/ok-to-test |
/lgtm |
/retest |
/lgtm |
@@ -260,6 +260,11 @@ type volumeManager struct { | |||
func (vm *volumeManager) Run(sourcesReady config.SourcesReady, stopCh <-chan struct{}) { | |||
defer runtime.HandleCrash() | |||
|
|||
if vm.kubeClient != nil { |
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.
curious why this had to move
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.
not necessary here but the sooner to populate the csi driver lister cache before desire workload state populator starts the better. racing is still there tho. Michelle opened an issue to figure out the place to start WaitForCacheSync
.
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.
racing is still there though
what is the impact of losing the race? functional failure or longer startup time?
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.
@zshihang and I discussed. The impact is NodePublish (mount) may be called without the token. The CSI driver is expected to fail if it expects one. The volume reconciler will retry NodePublish until successful.
@@ -1027,6 +1027,7 @@ func (pm *VolumePluginMgr) Run(stopCh <-chan struct{}) { | |||
// start informer for CSIDriver | |||
informerFactory := kletHost.GetInformerFactory() | |||
informerFactory.Start(stopCh) | |||
informerFactory.WaitForCacheSync(stopCh) |
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.
For this feature, if there isn't any negative effect from the informer being not in sync, then I'm ok with not waiting on it, and letting a retry resolve itself.
is this still outstanding? should WaitForCacheSync be removed?
} | ||
|
||
outputs := map[string]string{} | ||
for _, tokenRequest := range csiDriver.Spec.TokenRequests { |
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.
how frequently is republish called? do we recreate all tokens on every republish call or do we reuse the previously requested one if it is still valid?
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.
100ms between republish calls. the tokens are cached in kubelet. it is using the same handler as projected tokens.
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.
does that mean we're calling the CSI driver every 100ms?
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.
no because every reconciler loop takes some time and the reconciler loop calls republish.
kubernetes/pkg/kubelet/volumemanager/reconciler/reconciler.go
Lines 80 to 81 in 8be0a29
// loopSleepDuration - the amount of time the reconciler loop sleeps between | |
// successive executions |
from what i observed from e2e test, it is about 2~3/second.
no, this will be called in a go routine. it is better to have it happen sooner. @msau42 |
/approve API and validation changes look good. I did not review the volume plugin changes. Needs rebase, and storage reviewers have lgtm on remaining items. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, msau42, zshihang 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 |
/retest |
/lgtm |
/retest |
1 similar comment
/retest |
What type of PR is this?
What this PR does / why we need it:
KEP: kubernetes/enhancements#1855
Issue: #86448
release: kubernetes/enhancements#2047
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: