jiebi/CodeConvo huggingface dataset:
Code change:
return false, nil } <ins> func (f *FakeMounter) EvalHostSymlinks(pathname string) (string, error) { return pathname, nil } </ins> func (f *FakeMounter) PrepareSafeSubpath(subPath Subpath) (newHostPath string, cleanupAction func(), err error) { return subPath.Path, nil, nil }

Related discussion:
text: There is no such thing as /vdb and /dev/vdb is still intact of course. Seems inconsequential since it is disappearing after all pods using the device are deleted, i.e. it's still serving as a refcounter
Code change:
"github.com/vmware/govmomi/object" "github.com/vmware/govmomi/vim25/mo" <del> "k8s.io/klog/v2" </del> v1 "k8s.io/api/core/v1" <ins> "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> k8stypes "k8s.io/apimachinery/pkg/types" <ins> coreclients "k8s.io/client-go/kubernetes/typed/core/v1" corelisters "k8s.io/client-go/listers/core/v1" </ins> cloudprovider "k8s.io/cloud-provider" <ins> "k8s.io/klog/v2" </ins> "k8s.io/legacy-cloud-providers/vsphere/vclib" )

Related discussion:
text: I am enabling CSI migration on a vSphere cluster. A node was fully drained, all its Pods are deleted, but just before KCM detaches in-tree vSphere volume volumes from it, KCM restarts. A new KCM starts, sees attached volumes in that are not needed by any Pod on the node and calls vSphere in-tree volume plugin . The in-tree vSphere volume plugin + cloud provider marks the volume as detached right away, without reaching to vCenter API. The volume remains attached forever. I don't think it's related to CSI migration, IMO a regular node drain + KCM restart at the same time can cause the same issue. KCM logs: The in-tree cloud provider has a and from it. It apparently has not processed all nodes at the time A/D controller tries to detach the node. The in-tree vSphere volume plugin + cloud provider detaches the volume in vCenter. That's really tricky, it's very hard / impossible to reproduce on a real cluster. I had to inject errors to Detach() in-tree volume call, so they fail until KCM is restarted. Newly started KCM would detach the volume just fine (no error would be injected there), but marks the volume as detached right away. For the record (and search-ability), the CSI driver that tries to attach the volume to another node complains either: Or: cc It could be somewhat related to , however, not all cases of can be related to KCM restart. As I mentioned above, it's very hard/impossible to synchronize KCM restart with draining a node in a real cluster. <details</details<detailsvSphere 7.0.3 </details<details</details<detailsOpenShift </details<detailsCRI-O </details<details</details
/sig storage
Tried just moving a Pod between nodes without CSI migration involved + restarting KCM when the volume is still attached to the old node. In-tree volume plugin on the new node says:
/assign
What CSI driver version and K8s version are you testing with?
Kubernetes is 1.25 and CSI driver is 2.7, still, I think it's not releated to the CSI driver, it's KCM who marks the in-tree volume as detached due to not populated node cache.
Code change:
"github.com/vmware/govmomi/object" "github.com/vmware/govmomi/vim25/mo" <del> "k8s.io/klog/v2" </del> v1 "k8s.io/api/core/v1" <ins> "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> k8stypes "k8s.io/apimachinery/pkg/types" <ins> coreclients "k8s.io/client-go/kubernetes/typed/core/v1" corelisters "k8s.io/client-go/listers/core/v1" </ins> cloudprovider "k8s.io/cloud-provider" <ins> "k8s.io/klog/v2" </ins> "k8s.io/legacy-cloud-providers/vsphere/vclib" )

Related discussion:
text: /assign
/triage accepted
I found an easier way how to reproduce this without extra code in KCM: a StatefulSet with 1 Pod that uses 1 PVC. the node where the Pod runs. down kube-controller-manager to zero (not really possible for me) or kill all kube-controller-manager Pods. This will cause new KCM processes to wait for leader election. In my env. this gives me ~30 seconds for the next step. Delete the Pod. A new one will be scheduled on a different node (because the current node is cordoned) + there is no KCM running at this time that would detach the volume from the old node. KCM wins its leader election, sees a volume attached to a node where it is not needed -it calls of the volume plugin. VSphere cloud provider does not have its caches populated yet (= this bug) -the volume is not detached, but returns success.
dangling attach does not help here. The volume is still attached to the old node even after ~10 minutes. fails with and not with . I can see there is a lot of dangling attach code in the cloud provider, but I did not debug further.
Code change:
if index != -1 { // Delete element `index` <del> addr_pairs[index] = addr_pairs[len(routes)-1] addr_pairs = addr_pairs[:len(routes)-1] </del> <ins> addr_pairs[index] = addr_pairs[len(addr_pairs)-1] addr_pairs = addr_pairs[:len(addr_pairs)-1] </ins> unwind, err := updateAllowedAddressPairs(r.network, &port, addr_pairs) if err != nil {

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: After starting controller manager, get the following panic: /---------------------------------- I0712 08:54:30. 1 ] Deleting route 10.245.1.0/24 10.245.1.0/24 I0712 08:54:30. 1 ] Creating route for node ab-6l35lzekrg-0-7igjn3vr43tw-kube-minion-abhezrwnqucq 10.245.1.0/24 with hint -655c-11e7-9a48-, throttled 1.602µs I0712 08:54:30. 1 ] Creating route for node ab-hfvphu5tyl-0-623ksgxczeoh-kube-master-oevhfzd3xo7s 10.245.0.0/24 with hint -655c-11e7-9a48-, throttled 651ns I0712 08:54:31. 1 ] Created route for node ab-6l35lzekrg-0-7igjn3vr43tw-kube-minion-abhezrwnqucq 10.245.1.0/24 with hint -655c-11e7-9a48- after 349.278413ms I0712 08:54:32.
Code change:
if index != -1 { // Delete element `index` <del> addr_pairs[index] = addr_pairs[len(routes)-1] addr_pairs = addr_pairs[:len(routes)-1] </del> <ins> addr_pairs[index] = addr_pairs[len(addr_pairs)-1] addr_pairs = addr_pairs[:len(addr_pairs)-1] </ins> unwind, err := updateAllowedAddressPairs(r.network, &port, addr_pairs) if err != nil {

Related discussion:
text: 1 ] Created route for node ab-hfvphu5tyl-0-623ksgxczeoh-kube-master-oevhfzd3xo7s 10.245.0.0/24 with hint -655c-11e7-9a48- after 1.583805322s panic: runtime error: index out of range goroutine 1250 [running]: panic(0x3a3d4e0, 0xc42001a080) +0x1a1 (Routes).DeleteRoute(0xc4212e15a0, 0x40ff60e, 0xa, 0xc421bf22a0, 0x0, 0x0) +0x7d5 (RouteController).reconcile.func2(0xc4210bed70, 0xc421bf05e0, 0xc421bf22a0, 0xed0f7dac6, 0x3264f461, 0x6f143e0) +0x15a created by (RouteController).reconcile +0x6e6 /---------------------------------- What you expected to happen: Successed to delete route. How to reproduce it (as minimally and precisely as possible): verytime Anything else we need to know?: Environment: Kubernetes version (use ): v1.6.4 Cloud provider or hardware configuration*: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: cc /sig-openstack
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
cc
Reiterating the mentions to trigger a notification: <detailsIn response to : cc 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:
- /eventer - --source=kubernetes:'' - --sink=influxdb:http://monitoring-influxdb:8086 <del> - image: gcr.io/google_containers/addon-resizer:1.5 </del> <ins> - image: gcr.io/google_containers/addon-resizer:1.6 </ins> name: heapster-nanny resources: limits:

Related discussion:
text: HPA tests are currently failing in gke-large cluster suite: I did some debugging and the problem seems to be related to pod-nanny. Looking into logs from the last run: was first scheduled on the large node dedicated to it pod-nany updated heapster deployment then heapster was scheduled on the normal node (when it actually shouldn't fit) that point it was never updated by the pod nanny. that point, heapster started crashlooping (OOMing) [which in fact was expected in too small machine] So it's pretty clear that that pod-nanny changed the amount of resources to something smaller, which in fact it shouldn't.
Code change:
source := framework.NewFakeControllerSource() // Let's do threadsafe output to get predictable test results. <del> outputSetLock := sync.Mutex{} outputSet := util.StringSet{} </del> <ins> deletionCounter := make(chan string, 1000) </ins> // Make a controller that immediately deletes anything added to it, and // logs anything deleted.

Related discussion:
text: From shippable, I noticed there are several failed cases, for example, E0413 17:34:38. ] watch of *api.Pod ended with: Stop requested --- FAIL: Example (0.61s) got: want: a-hello b-controller c-framework FAIL coverage: 85.9% of statements FAIL 7.652s cc/
another example:
ah-- this is a different thing. I will fix this, too.
I'm seeing this from an unrelated change
Yeah I think that's the one I expected to see.
Code change:
// klog.V(4).Infof("rbd: info %s using mon %s, pool %s id %s key %s", b.Image, mon, b.Pool, id, secret) output, err = b.exec.Run("rbd", <del> "info", b.Image, "--pool", b.Pool, "-m", mon, "--id", id, "--key="+secret, "--format=json") </del> <ins> "info", b.Image, "--pool", b.Pool, "-m", mon, "--id", id, "--key="+secret, "-k=/dev/null", "--format=json") </ins> if err, ok := err.(*exec.Error); ok { if err.Err == exec.ErrNotFound {

Related discussion:
text: What happened: The rbd plugin use "rbd info" error: The messages before and after json result is warning string and no effect to rbd info, but it is effect to parse the output. So the kubernetes will failed: What you expected to happen: Kubernete no failed and errors How to reproduce it (as minimally and precisely as possible): Remove the config file
/sig storage
We are blocked by this issue, can't resize any PVCs
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
That is another situation that cluster configuation is empty, aslo will return lots of warnning information: Also will trigger expand volume failed. But should we add -c=/dev/null in rbd info command?
Folks, the pull request that would have fixed this just got closed as it was rotting away. This is an actual problem in production, can we please fix this?
+1 we are still being plagued by this issue...
+1 {"name":"kubernetes-dynamic-pvc--147e-422c-9e67-","size":,"objects":2560,"order":22,"objectsize":,"blocknameprefix":"rbddata.","format":2,"features":["layering"],"flags":[]}, invalid character '-' after top-level value
I solved by exceuting this command
Wow...I was not expecting this to work ... but it did ;) Any insights on why is it working with just the presence of the file? This is very strange... Appreciate any comments...
Code change:
testRCReleaseControlledNotMatching(f) }) <del> ginkgo.It("[Flaky] should test the lifecycle of a ReplicationController", func() { </del> <ins> /* Release: v1.20 Testname: Replication Controller, lifecycle Description: A Replication Controller (RC) is created, read, patched, and deleted with verification. */ framework.ConformanceIt("should test the lifecycle of a ReplicationController", func() { </ins> testRcName := "rc-test" testRcNamespace := ns testRcInitialReplicaCount := int32(1)

Related discussion:
text: [x] Original approval issue: Start 9 June 2020 3 Flakes No Flakes for 2 weeks According to this APIsnoop query, there are still some remaining ReplicationController endpoints which are untested. a ReplicationController with a static label the ReplicationController with a new Label and updated data the ReplicationController's status /Scale the ReplicationController's Replica count to 2 Replicas the ReplicationController the ReplicationController's Status all ReplicationControllers in all Namespaces find the ReplicationControllers(1) ensure that the ReplicationController is found and is patched Namespaced ReplicationControllers(1) via a Collection with a LabelSelector Discover useragents: See all endpoints hit from this test Display test coverage change If a test with these calls gets merged, test coverage will go up by 7 points This test is also created with the goal of conformance promotion.
/sig testing /sig architecture /area conformance
Can you please add in PR
/reopen Merged. Promotion to be created
Reopened this issue. <detailsIn response to : /reopen 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
/remove-lifecycle stale
Code change:
<del> 1.0 </del> <ins> 1.0.1 </ins>

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: e2e tests which use RBD server image fail with What you expected to happen: These tests succeed. How to reproduce it (as minimally and precisely as possible): Run e2e tests which use RBD server image. Anything else we need to know?: /sig storage This issue is introduced by below commit: It change the base image from fedora 26 to fedora 28. In fedora 26, hostname command is installed as a dependency for  However, in fedora 28, it is not installed, as a result, this issue happens due to lack of hostname command. Environment: Kubernetes version (use ): k8s 1.12 alpha
Please see the difference of the behaviour between fedora 26 and 28. [Fedora26] [Fedora28]
Could you help solving this issue? I assume the fix for the code would be as below, but I'm not familiar with the build and push process for the test image. ( in doesn't work.) So, I need your help to make further progress.
(or) Both need to be run from directory
Thank you for letting me know it. It should be s/all-containers/all-container/, but it seems to work. I will test with above patch and above build commands, then make a PR, once I confirm that it works well.
sorry typing from memory :)
I need to ask you two more things: Do we need to increment the version for this image, like 1.0.1, even for this small change? (I guess that and test/images/volume/rbd/VERSION will need to be updated in this case.) How the image push process will be? Does it pushed by CI, if there are a change in the code or docker file, or do someone who have permission will push it manually?
creates below three docker images: Is my understanding right that to make each test access to each arch image, needs to be modified like below? (Without doing so, each test seems to keep trying to access to , without arch.)
For fedora28 image, just installing hostname doesn't seem to work well. Please see the log below and attached . I guess that this is due to the difference of ceph version, which will be beyond my beyond my expertise.
Code change:
<del> 1.0 </del> <ins> 1.0.1 </ins>

Related discussion:
text: So, could you help debugging this issue? Meanwhile, I will try testing with the image by using fedora26 for workaround.
I confirmed that below commit, which change the base image back to fedora 26, fix this issue. Please see the log . After I checked the image-, I come to think that by pushing the image, each image will be able to be pulled without -arch, so I guess the last parameter for ImageConfig should be false. (I couldn't test it in my environment.) I will fix the commit as so and make a PR once I confirm it. Also, if it will easy to fix with Fedora 28, I will wait for the actual fix and quit making a PR for the workaround.
thanks yes, a quick fix is welcome, looking forward
Thank you for your comment. I will continue with the workaround. I saw a commit for deleting multi arch consideration. I rebased the patch to the commit and made a PR. Please review it.
Code change:
**All done !** <del> You can also use kubectl command to see if the newly created k8s is working correctly. </del> <ins> You can also use `kubectl` command to see if the newly created k8s is working correctly. The `kubectl` binary is under the `cluster/ubuntu/binaries` directory. You can move it into your PATH. Then you can use the below command smoothly. </ins> For example, use `$ kubectl get minions` to see if you get all your minion nodes comming up and ready. It may take some times for the minions be ready to use like below.

Related discussion:
text: Though I have successfully installed kubernetes via :smiley: , still want to point out this doc missing the step to install . Thus, if user just follow the guide in the doc without having much knowledge about kubernetes, he/she would get error "It looks as if you don't have a compiled kubectl binary" during the step of . Manually install kubectl on at least master node should be necessary (suggest to let user also install on minion node for convenience), any way, the installation step is .
I forget to mention that.I will update the doc this tuned
I update the scripts in pr , you can try it now. I copied the kubectl binary from the kubernetes release and put it in , so there is no extra step for user to manually download . Actually, in the first version of ubuntu k8s deployment, I copied the to every node, but I think it is an overhead, so I removed it.I think this is just enough.
Doc update : Move the kubectl into the PATH, it may need sudo privilege so I decide not do for the user.
Have the same issue, please update the doc ASAP.
Great job :+1:
Also ran into this bug after recklessly running ( instead of ) :)
Code change:
var enqueued bool cases := []struct { <del> test          string newNode       *v1.Node oldNode       *v1.Node ds            *apps.DaemonSet shouldEnqueue bool </del> <ins> test               string newNode            *v1.Node oldNode            *v1.Node ds                 *apps.DaemonSet expectedEventsFunc func(strategyType apps.DaemonSetUpdateStrategyType) int shouldEnqueue      bool </ins> }{ { test:    "Nothing changed, should not enqueue",

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: a cluster, And node1 with resource 1 DaemonSet, request resource 4 run , There is no pod created. resource to the node: run , There is still no pod created. What you expected to happen: In step 5, There is one pod created. How to reproduce it (as minimally and precisely as possible): see above description Anything else we need to know?: Environment: Kubernetes version (use ):1.10.5 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release):CentOS7 Kernel (e.g. ): Install tools: Others: /sig app
xref
Thanks! is not work here! Because: DaemonSetsController didn't watch the changes.(we use to updateNode.) we restart kubelet, The DaemonSetsController watch the changes, but it seems that the node info is not updated, and still failed to create pod:
I found it is a bug here, ignore the changes. I made a fix , PTAL! Thanks!
Any workarounds for old cluster versions? Up: looks like in my case helped but after some delay.
, which version of k8s are you using? If it's sunset, you have to merge the pr yourself :). I think restart kubelet trigger delete/add to make sure it sync .
Sorry, I didn't say
I think we still support 1.12 for now :) let's cherry pick it if not and wait for next 1.12 release.
Code change:
} func (f *fakeAttachDetachVolumeHost) CSINodeLister() storagelistersv1.CSINodeLister { <del> // not needed for testing return nil </del> <ins> csiNode := &storagev1.CSINode{ ObjectMeta: metav1.ObjectMeta{Name: f.nodeName}, Spec: storagev1.CSINodeSpec{ Drivers: []storagev1.CSINodeDriver{}, }, } enableMigrationOnNode(csiNode, csilibplugins.GCEPDInTreePluginName) return getFakeCSINodeLister(csiNode) } func enableMigrationOnNode(csiNode *storagev1.CSINode, pluginName string) { nodeInfoAnnotations := csiNode.GetAnnotations() if nodeInfoAnnotations == nil { nodeInfoAnnotations = map[string]string{} } newAnnotationSet := sets.NewString() newAnnotationSet.Insert(pluginName) nas := strings.Join(newAnnotationSet.List(), ",") nodeInfoAnnotations[v1.MigratedPluginsAnnotationKey] = nas csiNode.Annotations = nodeInfoAnnotations </ins> } func (f *fakeAttachDetachVolumeHost) CSIDriverLister() storagelistersv1.CSIDriverLister {

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:
<ins> /* Copyright 2023 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package topologymanager import ( "k8s.io/api/core/v1" "k8s.io/kubernetes/pkg/kubelet/cm/containermap" "k8s.io/kubernetes/pkg/kubelet/lifecycle" ) type noneScope struct { scope } // Ensure noneScope implements Scope interface var _ Scope = &noneScope{} // NewNoneScope returns a none scope. func NewNoneScope() Scope { return &noneScope{ scope{ name:             noneTopologyScope, podTopologyHints: podTopologyHints{}, policy:           NewNonePolicy(), podMap:           containermap.NewContainerMap(), }, } } func (s *noneScope) Admit(pod *v1.Pod) lifecycle.PodAdmitResult { return s.admitPolicyNone(pod) } </ins>

Related discussion:
text: Follow up from: See details there. When is , there is no need to discover the NUMA topology. /sig node /priority backlog /kind feature /help-wanted
/cc
/triage accepted
I would like to take this up also can I get more brief information about it? code review comments from asking that inside the NewManager() implementation, we need to skip NewPolicyOptions and NewNUMAInfo but when the NumaTopology comes kubelet issue also comes. I need some more information to start with this!
/cc
When there is no topology manger policy specified, NewManager should be a no-op. Just skip all checks.
Exactly. Just to add: we may need few iterations over the change to get a clean flow in the call.
/assign