jiebi/CodeConvo huggingface dataset:
Code change:
return f } <ins> type CSINodeLister []storagev1.CSINode // Get returns a fake CSINode object. func (n CSINodeLister) Get(name string) (*storagev1.CSINode, error) { for _, cn := range n { if cn.Name == name { return &cn, nil } } return nil, fmt.Errorf("csiNode %q not found", name) } // List lists all CSINodes in the indexer. func (n CSINodeLister) List(selector labels.Selector) (ret []*storagev1.CSINode, err error) { return nil, fmt.Errorf("not implemented") } func getFakeCSINodeLister(csiNode *storagev1.CSINode) CSINodeLister { csiNodeLister := CSINodeLister{} if csiNode != nil { csiNodeLister = append(csiNodeLister, *csiNode.DeepCopy()) } return csiNodeLister } </ins> func (f *fakeKubeletVolumeHost) SetKubeletError(err error) { f.mux.Lock() defer f.mux.Unlock()

Related discussion:
text: After the cluster was updated to enable PD CSI Driver, there was a race condition where AD Controller (kube-controller-manager) started to BEFORE the PD CSI Driver was up, thus AD Controller gave us the error Then AD Controller triggered the disk detach because the disk/volume was not populated in the desired state of world. Unfortunately the disk was in use during this detach and got corrupted. Since cluster upgrades can cause the controller manager and CSI drivers to start at different times, the AD controller needs to be more conservative when detaching We have not been able to reproduce this, it came up from a customer. /sig storage /assign <detailsk8s 1.23, CSI migration enabled </details<detailsGKE </details<details</details<details</details<details</details<details</details
/triage accepted
I think there's potentially two changes we should do: 1) for the initial DSW population, we should skip the check that if the csi driver is not installed. 2) in general, we should not skip volumes during dsw initial population if an error is returned. If we had some temporary api server error then that would cause volumes to not get to dsw and similar behavior happen. cc
for a repro, maybe you can try something like: a cluster with csi migration enabled (control plane + nodes) a pod with intree-volume and get it running the csi driver node daemonset. verify the driver is removed from CSINode kube-controller-manager
cc
/cc was trying to repro this, but on GKE with the managed driver which made it complicated.
Yeah maybe gce kube-up would be easier for a repro
If CSINode says that it has migrated GCP PD volume plugin to CSI, then IMO A/D controller should always attach GCP PD volumes to it using CSI, regardless if the CSI driver is present or not. In-tree volume plugin in the kubelet is disabled and can't mount any in-tree volumes anyway. To flip the migration feature gate / upgrade / downgrade kubelet, the cluster admin must drain the node first to make sure everything is detached. A/D controller should not see change of CSINode migration annotations with any volume attached to it.
/priority important-soon
Another option could be to process these volumes anyways but add them to DSOW with migration status as "uncertain", so as they can be re-processed later.
Code change:
return f } <ins> type CSINodeLister []storagev1.CSINode // Get returns a fake CSINode object. func (n CSINodeLister) Get(name string) (*storagev1.CSINode, error) { for _, cn := range n { if cn.Name == name { return &cn, nil } } return nil, fmt.Errorf("csiNode %q not found", name) } // List lists all CSINodes in the indexer. func (n CSINodeLister) List(selector labels.Selector) (ret []*storagev1.CSINode, err error) { return nil, fmt.Errorf("not implemented") } func getFakeCSINodeLister(csiNode *storagev1.CSINode) CSINodeLister { csiNodeLister := CSINodeLister{} if csiNode != nil { csiNodeLister = append(csiNodeLister, *csiNode.DeepCopy()) } return csiNodeLister } </ins> func (f *fakeKubeletVolumeHost) SetKubeletError(err error) { f.mux.Lock() defer f.mux.Unlock()

Related discussion:
text: But surely it looks like might be easiest unless it has any downsides.
There wasn't a node update in this case---there was a control plane update which restarted the PD CSI driver, and it looks like the CSIDriver resource was updated or changed in some way which raced with the kube-controller-manager restart.
Is there anyway we can know if the csi driver is up and running(like a health check ping) before populating DSW?
We use the CSINode registration to determine that. The discussion here I think is concluding that we should not use that as a criteria for adding the volume to DSW. We only need to check that CSI migration is enabled on the node.
+1 we need to be very resilient against races, I think we have to assume a driver is in process of being installed at any point in the AD controller reconcilliation.
/assign sunnylovestiramisu
Reproduced with the steps: In /var/log/kube-controller-
Tested with the and doing the reproduce steps above. The error of does not show up anymore. The error message still get logged in the kube-controller- for debugging purpose: Ran Ran On the GCP console, the disk is used by node: Ran I redeploy the pd-csi-driver and then make sure it is up and running. Ran
Code change:
containers: # TODO: Add resources in 1.8 - name: event-exporter <del> image: gcr.io/google-containers/event-exporter:v0.1.0-r2 </del> <ins> image: gcr.io/google-containers/event-exporter:v0.1.4 </ins> command: - '/event-exporter' - name: prometheus-to-sd-exporter

Related discussion:
text: Every time watch is reset, event exporter exports an entry about it to Stackdriver. To make it less irritating, this has to be done once per container run Related image PR: /cc
Code change:
} func (c *LRUExpireCache) Get(key lru.Key) (interface{}, bool) { <del> c.lock.RLock() defer c.lock.RUnlock() </del> <ins> c.lock.Lock() defer c.lock.Unlock() </ins> e, ok := c.cache.Get(key) if !ok { return nil, false

Related discussion:
text: Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "LRUExpireCache" Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT What happened: requires write lock since needs to manipulate its list to track recently used item. Currently it uses read lock so it may introduce race condition. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else do we need to know:
This was fixed in
Code change:
return isDummyVMPresent, nil } <ins> func (vs *VSphere) GetNodeNameFromProviderID(providerID string) (string, error) { var nodeName string nodes, err := vs.nodeManager.GetNodeDetails() if err != nil { glog.Errorf("Error while obtaining Kubernetes node nodeVmDetail details. error : %+v", err) return "", err } for _, node := range nodes { // ProviderID is UUID for nodes v1.9.3+ if node.VMUUID == GetUUIDFromProviderID(providerID) || node.NodeName == providerID { nodeName = node.NodeName break } } if nodeName == "" { msg := fmt.Sprintf("Error while obtaining Kubernetes nodename for providerID %s.", providerID) return "", errors.New(msg) } return nodeName, nil } </ins> func GetVMUUID() (string, error) { id, err := ioutil.ReadFile(UUIDPath) if err != nil {

Related discussion:
text: As planned for 1.12 in kubernetes/features: After , the next step is to add the logic to the reconciler to detach the volumes when the nodeShutdown taint is applied. /assign /sig storage /kind feature looping
How do you know that node is Shutdown? is it a planned shutdown or a unplanned shutdown?
AFAIK regardless of whether it's planned or not, it's detected by the cloud provider. In case of bare-metal node it doesn't happen automatically, as there is no universal way to reliably determine if a node is powered off, so the node must be tainted as by some external source.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
any update on this issue?
, I am currently working with sig-node team on handling node shut down. I will make a proposal and discuss in sig-node meeting next Tuesday. Will post the update soon.
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten /kind bug /priority critical-urgent /assign /sig node
Those labels are not set on the issue: <detailsIn response to : /remove-kind feature Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
any update on this? is it going to be part of 1.15?
Stale issues rot after 30d of inactivity. Mark the issue as fresh with .
Code change:
return isDummyVMPresent, nil } <ins> func (vs *VSphere) GetNodeNameFromProviderID(providerID string) (string, error) { var nodeName string nodes, err := vs.nodeManager.GetNodeDetails() if err != nil { glog.Errorf("Error while obtaining Kubernetes node nodeVmDetail details. error : %+v", err) return "", err } for _, node := range nodes { // ProviderID is UUID for nodes v1.9.3+ if node.VMUUID == GetUUIDFromProviderID(providerID) || node.NodeName == providerID { nodeName = node.NodeName break } } if nodeName == "" { msg := fmt.Sprintf("Error while obtaining Kubernetes nodename for providerID %s.", providerID) return "", errors.New(msg) } return nodeName, nil } </ins> func GetVMUUID() (string, error) { id, err := ioutil.ReadFile(UUIDPath) if err != nil {

Related discussion:
text: Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/priority important-longterm
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /lifecycle frozen
/triage accepted /kind feature
This issue has not been updated in over 1 year, and should be re-triaged. You can: Confirm that this issue is still relevant with (org members only) Close this issue with For more details on the triage process, see /remove-triage accepted
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I think this can be closed now as we have non-graceful node shutdown.
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Code change:
defer logs.FlushLogs() if err := command.Execute(); err != nil { <del> fmt.Fprintf(os.Stderr, "error: %vn", err) </del> os.Exit(1) } }

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: kubectl version --client=yes command is giving the following error message. Error message is repeated at the start and the end and also containing programming jargon Error: invalid argument "yes" for "--client" flag: strconv.ParseBool: parsing "yes": invalid syntax Examples: Print the client and server versions for the current context kubectl version Options: --client=false: Client version only (no server required). -o, --output='': One of 'yaml' or 'json'. --short=false: Print just the version number. Usage: kubectl version [flags] [options] Use "kubectl options" for a list of global command-line options (applies to all commands). invalid argument "yes" for "--client" flag: strconv.ParseBool: parsing "yes": invalid syntax What you expected to happen: The error message can be improved with one of the two variants invalid argument "yes" for "--client" flag Examples: Print the client and server versions for the current context kubectl version Options: --client=false: Client version only (no server required). -o, --output='': One of 'yaml' or 'json'. --short=false: Print just the version number. Usage: kubectl version [flags] [options] Use "kubectl options" for a list of global command-line options (applies to all commands). (or) Invalid argument "yes" for "--client" flag How to reproduce it (as minimally and precisely as possible): Run the command kubectl version --client=yes Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: AWS OS (e.g: ): Amazon Linux Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cli
Hi Thanks for posting this issue! It turns out that this duplicate output has been in kubectl, and all the other cli cmds, since . This should be fixed by , and hopefully we can cherry pick it back to at least .
Code change:
// Register registers the device plugin for the given resourceName with Kubelet. func (m *Stub) Register(kubeletEndpoint, resourceName string) error { <del> conn, err := grpc.Dial(kubeletEndpoint, grpc.WithInsecure(), </del> <ins> conn, err := grpc.Dial(kubeletEndpoint, grpc.WithInsecure(), grpc.WithBlock(), grpc.WithTimeout(10*time.Second), </ins> grpc.WithDialer(func(addr string, timeout time.Duration) (net.Conn, error) { return net.DialTimeout("unix", addr, timeout) }))

Related discussion:
text: This is not 100% reproducable in my cluster. There is 20% chance of failing in my environment.
/area hw-accelerators mentioned a root cause that might be due to unit tests sharing the same Unix socket and interfering with each others. cc
Can you please share latest commit id of your code base using ?
Thanks very much, can you try the follow command please:
/assign
The latest commit id of my code base:
I found this is not 100% reproducable in my cluster. There is 20% chance of failing in my environment.
Result of go test command:
/sig scheduling
Thanks!
Hi, does these unit tests pass with PR
I run 100 times without failure.
Good to here that, Nice work! Thanks!
Code change:
[[projects]] name = "github.com/modern-go/reflect2" packages = ["."] <del> revision = "1df9eeb2bb81f327b96228865c5687bc2194af3f" version = "1.0.0" </del> <ins> revision = "4b7aa43c6742a2c18fdef89dd197aaae7dac7ccd" version = "1.0.1" </ins> [solve-meta] analyzer-name = "dep" analyzer-version = 1 <del> inputs-digest = "56a0b9e9e61d2bc8af5e1b68537401b7f4d60805eda3d107058f3171aa5cf793" </del> <ins> inputs-digest = "ea54a775e5a354cb015502d2e7aa4b74230fc77e894f34a838b268c25ec8eeb8" </ins> solver-name = "gps-cdcl" solver-version = 1

Related discussion:
text: is a library yet is is instead of release tag. Please consider vendoring by tag whenever possible. Thanks.
We vendored it that way because the commit that fixed a bug (which we needed to be fixed and vendored back in) was This was merged on June 13. The release 1.1.4 () was released on July 1. If we want to update it to 1.1.4, I believe it should be fine. Between the commit we have vendored right now and the latest release, there are only three commits: adds tests merges (?) the case-sensitive fix - I'm not really sure what this commit is doing. fixes renaming when naming strategy is set (looks fine). Also, there are also no licensing changes. opinions?
/sig api-machinery
+1 to what said, it was a fire drill and 1.11.0 release was in trouble. Though in hind sight, we should have opened a issue to track that. something better to do next time. cc
I'm indifferent to updating this. I'm okay with moving up if it doesn't break anything, or I'm fine with leaving things as is. We don't require deps to match semver. We can version out any commit in a deps tree, as we rely on our vendored copy.
It is always a good idea to match semver and it should be a default policy. Even if it doesn't matter to you, it should, because it is a best practice. Moreover downstream it matters much more as dependencies may be un-vendored in favour of tested re-usable packages.
/cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Someone please take care of this or bot will eventually close this valid issue without action...
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .
Code change:
[[projects]] name = "github.com/modern-go/reflect2" packages = ["."] <del> revision = "1df9eeb2bb81f327b96228865c5687bc2194af3f" version = "1.0.0" </del> <ins> revision = "4b7aa43c6742a2c18fdef89dd197aaae7dac7ccd" version = "1.0.1" </ins> [solve-meta] analyzer-name = "dep" analyzer-version = 1 <del> inputs-digest = "56a0b9e9e61d2bc8af5e1b68537401b7f4d60805eda3d107058f3171aa5cf793" </del> <ins> inputs-digest = "ea54a775e5a354cb015502d2e7aa4b74230fc77e894f34a838b268c25ec8eeb8" </ins> solver-name = "gps-cdcl" solver-version = 1

Related discussion:
text: /lifecycle rotten
/lifecycle rotten
/remove-lifecycle rotten PR open (thanks,
oops! sorry, I meant to remove it. thanks!
Thanks.
please do feel free to open issues/prs of this sort early in the release cycle, so we can work through things needed well before the milestones/freeze etc. we are getting some heat about updating dependencies and we kind of settled on some guidelines here: if you think that needs updating, we could definitely debate that as well :) (on a PR against that doc)
it have nothing to do with release cycle or justification for upgrade if/when dependency has been vendored incorrectly. It is basically a vendoring bug. No debate is necessary although that kind of issues usually meet some resistance and even hostility here... Bugs are filed when they are discovered, regardless of release cycle. It would be wrong to sit on the bug without reporting it in order to synchronise with release cycle.
Code change:
}, { "ImportPath": "github.com/json-iterator/go", <del> "Comment": "1.1.3-22-gf2b4162afba355", "Rev": "f2b4162afba35581b6d4a50d3b8f34e33c144682" </del> <ins> "Comment": "1.1.4", "Rev": "ab8a2e0c74be9d3be70b3184d9acc634935ded82" </ins> }, { "ImportPath": "github.com/jteeuwen/go-bindata",

Related discussion:
text: is a library yet is is instead of release tag. Please consider vendoring by tag whenever possible. Thanks.
We vendored it that way because the commit that fixed a bug (which we needed to be fixed and vendored back in) was This was merged on June 13. The release 1.1.4 () was released on July 1. If we want to update it to 1.1.4, I believe it should be fine. Between the commit we have vendored right now and the latest release, there are only three commits: adds tests merges (?) the case-sensitive fix - I'm not really sure what this commit is doing. fixes renaming when naming strategy is set (looks fine). Also, there are also no licensing changes. opinions?
/sig api-machinery
+1 to what said, it was a fire drill and 1.11.0 release was in trouble. Though in hind sight, we should have opened a issue to track that. something better to do next time. cc
I'm indifferent to updating this. I'm okay with moving up if it doesn't break anything, or I'm fine with leaving things as is. We don't require deps to match semver. We can version out any commit in a deps tree, as we rely on our vendored copy.
It is always a good idea to match semver and it should be a default policy. Even if it doesn't matter to you, it should, because it is a best practice. Moreover downstream it matters much more as dependencies may be un-vendored in favour of tested re-usable packages.
/cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Someone please take care of this or bot will eventually close this valid issue without action...
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .
Code change:
}, { "ImportPath": "github.com/json-iterator/go", <del> "Comment": "1.1.3-22-gf2b4162afba355", "Rev": "f2b4162afba35581b6d4a50d3b8f34e33c144682" </del> <ins> "Comment": "1.1.4", "Rev": "ab8a2e0c74be9d3be70b3184d9acc634935ded82" </ins> }, { "ImportPath": "github.com/jteeuwen/go-bindata",

Related discussion:
text: /lifecycle rotten
/lifecycle rotten
/remove-lifecycle rotten PR open (thanks,
oops! sorry, I meant to remove it. thanks!
Thanks.
please do feel free to open issues/prs of this sort early in the release cycle, so we can work through things needed well before the milestones/freeze etc. we are getting some heat about updating dependencies and we kind of settled on some guidelines here: if you think that needs updating, we could definitely debate that as well :) (on a PR against that doc)
it have nothing to do with release cycle or justification for upgrade if/when dependency has been vendored incorrectly. It is basically a vendoring bug. No debate is necessary although that kind of issues usually meet some resistance and even hostility here... Bugs are filed when they are discovered, regardless of release cycle. It would be wrong to sit on the bug without reporting it in order to synchronise with release cycle.