jiebi/CodeConvo huggingface dataset:
Code change:
} } <ins> func TestInClusterClientConfigPrecedence(t *testing.T) { tt := []struct { overrides *ConfigOverrides }{ { overrides: &ConfigOverrides{ ClusterInfo: clientcmdapi.Cluster{ Server: "https://host-from-overrides.com", }, }, }, { overrides: &ConfigOverrides{ AuthInfo: clientcmdapi.AuthInfo{ Token: "https://host-from-overrides.com", }, }, }, { overrides: &ConfigOverrides{ ClusterInfo: clientcmdapi.Cluster{ CertificateAuthority: "/path/to/ca-from-overrides.crt", }, }, }, { overrides: &ConfigOverrides{ ClusterInfo: clientcmdapi.Cluster{ Server: "https://host-from-overrides.com", }, AuthInfo: clientcmdapi.AuthInfo{ Token: "https://host-from-overrides.com", }, }, }, { overrides: &ConfigOverrides{ ClusterInfo: clientcmdapi.Cluster{ Server:               "https://host-from-overrides.com", CertificateAuthority: "/path/to/ca-from-overrides.crt", }, }, }, { overrides: &ConfigOverrides{ ClusterInfo: clientcmdapi.Cluster{ CertificateAuthority: "/path/to/ca-from-overrides.crt", }, AuthInfo: clientcmdapi.AuthInfo{ Token: "https://host-from-overrides.com", }, }, }, { overrides: &ConfigOverrides{ ClusterInfo: clientcmdapi.Cluster{ Server:               "https://host-from-overrides.com", CertificateAuthority: "/path/to/ca-from-overrides.crt", }, AuthInfo: clientcmdapi.AuthInfo{ Token: "https://host-from-overrides.com", }, }, }, { overrides: &ConfigOverrides{}, }, } for _, tc := range tt { expectedServer := "https://host-from-cluster.com" expectedToken := "token-from-cluster" expectedCAFile := "/path/to/ca-from-cluster.crt" icc := &inClusterClientConfig{ inClusterConfigProvider: func() (*restclient.Config, error) { return &restclient.Config{ Host:        expectedServer, BearerToken: expectedToken, TLSClientConfig: restclient.TLSClientConfig{ CAFile: expectedCAFile, }, }, nil }, overrides: tc.overrides, } clientConfig, err := icc.ClientConfig() if err != nil { t.Fatalf("Unxpected error: %v", err) } if overridenServer := tc.overrides.ClusterInfo.Server; len(overridenServer) > 0 { expectedServer = overridenServer } if overridenToken := tc.overrides.AuthInfo.Token; len(overridenToken) > 0 { expectedToken = overridenToken } if overridenCAFile := tc.overrides.ClusterInfo.CertificateAuthority; len(overridenCAFile) > 0 { expectedCAFile = overridenCAFile } if clientConfig.Host != expectedServer { t.Errorf("Expected server %v, got %v", expectedServer, clientConfig.Host) } if clientConfig.BearerToken != expectedToken { t.Errorf("Expected token %v, got %v", expectedToken, clientConfig.BearerToken) } if clientConfig.TLSClientConfig.CAFile != expectedCAFile { t.Errorf("Expected Certificate Authority %v, got %v", expectedCAFile, clientConfig.TLSClientConfig.CAFile) } } } </ins> func matchBoolArg(expected, got bool, t *testing.T) { if expected != got { t.Errorf("Expected %v, got %v", expected, got)

Related discussion:
text: Found in openshift, but I'm pretty sure the codepaths are the same. That means the token is getting ignored and in-cluster config is being used in preference to flags.
Is a similar issue?
Yep, kind of regression.
Sigh.
Yes, most likely the same cause.
I'm on it.
Unit test :)
Probably will want to cherrypick this into 1.5.
WIP in
Code change:
// The name of this port. All ports in an EndpointSlice must have a unique // name. If the EndpointSlice is dervied from a Kubernetes service, this // corresponds to the Service.ports[].name. <del> // Name must either be an empty string or pass IANA_SVC_NAME validation: // * must be no more than 15 characters long // * may contain only [-a-z0-9] // * must contain at least one letter [a-z] // * it must not start or end with a hyphen, nor contain adjacent hyphens </del> <ins> // Name must either be an empty string or pass DNS_LABEL validation: // * must be no more than 63 characters long. // * must consist of lower case alphanumeric characters or '-'. // * must start and end with an alphanumeric character. </ins> Name *string // The IP protocol for this port. // Must be UDP, TCP, or SCTP.

Related discussion:
text: What happened: No endpoints created in the EndpointSlice for my service due to the port on the service being too long. Logs show: EndpointSlice created has no endpoint: What you expected to happen: Service that works with Endpoints should work with EndpointSlice. If this is intentional, it should be clearly documented How to reproduce it (as minimally and precisely as possible): Create a service with a long port name Environment: Kubernetes version (use ): 1.16 Cloud provider or hardware configuration: kind
/sig networking
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /sig networking 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
/sig network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
For a rough measure of impact, Istio had 5 ports that were over this limit (and many more that were right at 15 characters), so I suspect it may not be terribly rare.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
This needs to be resolved before endpointslices graduate from alpha
/assign
/remove-triage unresolved
Code change:
docs/man/man1/kubectl-alpha-diff.1 docs/man/man1/kubectl-alpha.1 docs/man/man1/kubectl-annotate.1 <ins> docs/man/man1/kubectl-api-resources.1 </ins> docs/man/man1/kubectl-api-versions.1 docs/man/man1/kubectl-apply-edit-last-applied.1 docs/man/man1/kubectl-apply-set-last-applied.1

Related discussion:
text: As the RBAC role need to be related to resources. I think we could use a command to get the supported resources. ref to
This would be cool.
I thought we a command that listed resources in the discover doc a long time ago.
is just the versions, but principle is the same. We want to list all the types, their resources, and tie that back to "explain".
What's the best way to determine this information currently? I'm having difficulty figuring out the exact set of permissions (and how they would be written in an RBAC role) for any given kubectl command. The documentation for this right now is split across multiple places and certain things are not explained at all. Specifically, it's difficult to determine which "API verb" is used for which operations. Take as an example. It's unclear if the way to allow this is to use the "proxy" subresource of a pod or service with "get"/"create"/etc. verbs, or to use the "proxy" verb with the resource (pod, service) directly. is a similar case. The almost works for this purpose, but it's still difficult. Operations for a given resource are grouped into categories like write, read, status, and proxy, but these things don't obviously correlate with API verbs. Again, proxy is especially confusing as there is no mention of a proxy "verb". The API operations are only shown using their HTTP verbs. One thing that could help on this document would be a section on the right column under "kubectl command" that shows exactly the rule needed in an RBAC role to allow this command via kubectl. And even then, that assumes an exact 1-to-1 mapping between API endpoints and kubectl commands, which I doubt is always the case. (For example, port fowarding to a pod seems to require both a GET on the pod resource and a CREATE on a port forward subresource.) There also needs to be better documentation about how this information could have been determined in the first place. I've resorted to manually looking through API requests made with but even then it's difficult to figure out. Amusingly, I was the one who wrote which is referenced in the original issue description (as well as the table explaining verbs in ).
Code change:
docs/man/man1/kubectl-alpha-diff.1 docs/man/man1/kubectl-alpha.1 docs/man/man1/kubectl-annotate.1 <ins> docs/man/man1/kubectl-api-resources.1 </ins> docs/man/man1/kubectl-api-versions.1 docs/man/man1/kubectl-apply-edit-last-applied.1 docs/man/man1/kubectl-apply-set-last-applied.1

Related discussion:
text: tl;dr: It's too difficult right now to go from "I want a user to be able to run " to "here is the RBAC rule to use for that" for any case where there isn't a specific example shown in the docs.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
It seem that relative PR stop updated. If this issue still valuable, i will help fix it
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 stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Code change:
maxStorageAccounts                     = 100 // max # is 200 (250 with special request). this allows 100 for everything else including stand alone disks maxDisksPerStorageAccounts             = 60 storageAccountUtilizationBeforeGrowing = 0.5 <ins> // Disk Caching is not supported for disks 4 TiB and larger // https://docs.microsoft.com/en-us/azure/virtual-machines/premium-storage-performance#disk-caching diskCachingLimit = 4096 // GiB </ins> maxLUN               = 64 // max number of LUNs per VM errLeaseFailed       = "AcquireDiskLeaseFailed"

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: there is a disk resize scenario: In the beginning, it’s 3TiB with cachingMode=ReadOnly, and then disk detached, resized to 4TiB, then user find they could not attach that disk back to any agent node, I think that’s a bug we need to fix. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
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
Code change:
// list all pods to include the pods that don't match the rs`s selector // anymore but has the stale controller ref. // TODO: Do the List and Filter in a single pass, or use an index. <del> pods, err := rsc.podLister.Pods(rs.Namespace).List(labels.Everything()) </del> <ins> allPods, err := rsc.podLister.Pods(rs.Namespace).List(labels.Everything()) </ins> if err != nil { return err } // Ignore inactive pods. var filteredPods []*v1.Pod <del> for _, pod := range pods { </del> <ins> for _, pod := range allPods { </ins> if controller.IsPodActive(pod) { filteredPods = append(filteredPods, pod) }

Related discussion:
text: https://k8s- Failed: [] Network Partition [Disruptive] [Slow] [] [ReplicationController] should eagerly create replacement pod during network partition when termination grace is non-zero {Kubernetes e2e suite}
https://k8s- seems to be the first failure here. It seems to have gone in with a bunch of RC/RS changes () cc/
Code change:
statuses[container.Name] = status } <ins> // Copy the slice before sorting it containerStatusesCopy := make([]*kubecontainer.Status, len(podStatus.ContainerStatuses)) copy(containerStatusesCopy, podStatus.ContainerStatuses) </ins> // Make the latest container status comes first. <del> sort.Sort(sort.Reverse(kubecontainer.SortContainerStatusesByCreationTime(podStatus.ContainerStatuses))) </del> <ins> sort.Sort(sort.Reverse(kubecontainer.SortContainerStatusesByCreationTime(containerStatusesCopy))) </ins> // Set container statuses according to the statuses seen in pod status containerSeen := map[string]int{} <del> for _, cStatus := range podStatus.ContainerStatuses { </del> <ins> for _, cStatus := range containerStatusesCopy { </ins> cName := cStatus.Name if _, ok := statuses[cName]; !ok { // This would also ignore the infra container.

Related discussion:
text: What happened: One pod stuck at CreateContainerError and can't get recovered automatically. Kubelet log shows that the requested name (let's say Container2) is already in use. shows the Container2 Running, and it's created before Container1 This should never happen. How to reproduce it (as minimally and precisely as possible): I wish i knew. Anything else we need to know?: I know this can be caused by time shifting, but I didn't find any time shifting sign in system log and chrony log, and there is no rebooting between the create timestamp of Container1 and Container2, so this should be caused by something else. This happens intermittently in our env, like 3 times in half a year, and I didn't find any ime shifting sign each time. Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-11-13T11:20:18Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-08-28T11:18:26Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g: ): CentOS Linux release 7.5.1804 (Core) Kernel (e.g. ): Linux node-1 3.10.0-957.21.3.el7.x8664 SMP Wed Jul 17 06:57:50 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others:
/sig node
Any update on this issue, we are also facing the same issue. EKS version : 1.14.9 Docker version: 19.03.6-ce AWS CNI: 1.6.2 Intermittently we are also facing this , what might the issue, could please guide us here? Below are the kubelet logs. )"
Code change:
statuses[container.Name] = status } <ins> // Copy the slice before sorting it containerStatusesCopy := make([]*kubecontainer.Status, len(podStatus.ContainerStatuses)) copy(containerStatusesCopy, podStatus.ContainerStatuses) </ins> // Make the latest container status comes first. <del> sort.Sort(sort.Reverse(kubecontainer.SortContainerStatusesByCreationTime(podStatus.ContainerStatuses))) </del> <ins> sort.Sort(sort.Reverse(kubecontainer.SortContainerStatusesByCreationTime(containerStatusesCopy))) </ins> // Set container statuses according to the statuses seen in pod status containerSeen := map[string]int{} <del> for _, cStatus := range podStatus.ContainerStatuses { </del> <ins> for _, cStatus := range containerStatusesCopy { </ins> cName := cStatus.Name if _, ok := statuses[cName]; !ok { // This would also ignore the infra container.

Related discussion:
text: with CreatePodSandboxError: "CreatePodSandbox for pod "-f0fe-11ea-9872-)" failed: rpc error: code = Unknown desc = failed to create a sandbox for pod "aiqx-server-dep--b9lmv": operation timeout: context deadline exceeded" Sep 07 11:40:40 kubelet[2899]: W0907 11:40:40. 2899 ] No ref for container "docker://7b9c86b529530f15d941f8e68973a202c8f348ab5db864a8371e8c82ddbf9dc4" (r(-e845-11ea-bd96-) Sep 07 11:40:43 kubelet[2899]: W0907 11:40:43. 2899 ] Unable to create pod sandbox due to conflict. Attempting to remove sandbox "a73bd9a03d56bc7855e4e89e163e13c5e7173397f10edcc200fb686e1b6885c8" Sep 07 11:40:43 kubelet[2899]: E0907 11:40:43. 2899 ] Failed to remove the conflicting container "a73bd9a03d56bc7855e4e89e163e13c5e7173397f10edcc200fb686e1b6885c8": Error: No such container: a73bd9a03d56bc7855e4e89e163e13c5e7173397f10edcc200fb686e1b6885c8
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
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:
statuses[container.Name] = status } <ins> // Copy the slice before sorting it containerStatusesCopy := make([]*kubecontainer.Status, len(podStatus.ContainerStatuses)) copy(containerStatusesCopy, podStatus.ContainerStatuses) </ins> // Make the latest container status comes first. <del> sort.Sort(sort.Reverse(kubecontainer.SortContainerStatusesByCreationTime(podStatus.ContainerStatuses))) </del> <ins> sort.Sort(sort.Reverse(kubecontainer.SortContainerStatusesByCreationTime(containerStatusesCopy))) </ins> // Set container statuses according to the statuses seen in pod status containerSeen := map[string]int{} <del> for _, cStatus := range podStatus.ContainerStatuses { </del> <ins> for _, cStatus := range containerStatusesCopy { </ins> cName := cStatus.Name if _, ok := statuses[cName]; !ok { // This would also ignore the infra container.

Related discussion:
text: /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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:
"k8s.io/apimachinery/pkg/util/diff" "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/sets" <ins> "k8s.io/kubernetes/federation/apis/federation" </ins> "k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/api/testapi" "k8s.io/kubernetes/pkg/apis/apps"

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: After labeling clusters in a Federation, when you type the field is empty. What you expected to happen: The fiels should contain information about the labels in the cluster How to reproduce it (as minimally and precisely as possible): a federation control pane in any Cloud Provider and any DNS provider your cluster: info aboyut the cluster with the flag: Note: if you describe it, you see the labels being : Environment: Kubernetes version (use ): 1.8.0 Cloud provider or hardware configuration**: anyone OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux Install tools: curl Others:
/sig multicluster
I'm working on it.
Code change:
}, } if strings.Contains(err.Error(), "0/3 nodes are available") { <del> if strings.Contains(err.Error(), "2 NodeUnderDiskPressure") && strings.Contains(err.Error(), "1 NodeUnderMemoryPressure") { </del> <ins> if strings.Contains(err.Error(), "2 node(s) had disk pressure") && strings.Contains(err.Error(), "1 node(s) had memory pressure") { </ins> return } }

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature The is not user friendly. There has been to make it better, but we still print in the pending message. We should change these errors to a more human readable message. For example, should be changed to something like . /sig scheduling
Code change:
} } <ins> if utilfeature.DefaultFeatureGate.Enabled(features.HonorPVReclaimPolicy) { if metav1.HasAnnotation(volume.ObjectMeta, storagehelpers.AnnMigratedTo) { // CSI migration scenario - do not depend on in-tree plugin return nil, nil } if volume.Spec.CSI != nil { // CSI volume source scenario - external provisioner is requested return nil, nil } } </ins> // The plugin that provisioned the volume was not found or the volume // was not dynamically provisioned. Try to find a plugin by spec. spec := vol.NewSpecFromPersistentVolume(volume, false)

Related discussion:
text: In my CSI controller I have enabled the feature gate HonorPVReclaimPolicy for csi-provisioner. Based on the documentation Finalizers can be on a PersistentVolume to ensure that PersistentVolumes having Delete reclaim policy are deleted only after the backing storage are deleted. The newly introduced finalizers and external- are only to dynamically provisioned volumes. I can see the finalizer set on the PV while creating static Persistent Volume. PV deletion is stuck due to this finalizer apiVersion: v1 kind: PersistentVolume metadata: creationTimestamp: "2023-11-08T11:39:24Z" deletionGracePeriodSeconds: 0 deletionTimestamp: "2023-11-08T11:54:31Z" finalizers: external- name: csi-infoscale-pv PV should be deleted when PVC is deleted. Persistent Volume yaml apiVersion: v1 kind: PersistentVolume metadata: name: csi-infoscale-pv spec: storageClassName: csi-infoscale-sc-prod persistentVolumeReclaimPolicy: Delete capacity: storage: 2Gi accessModes: ReadWriteOnce csi: driver: org.veritas.infoscale # Please provide pre-provisioned Infoscale volume name. volumeHandle: clust21432/vrtskube_dg-/vol1 fsType: vxfs Persistent Volume Claim apiVersion: v1 kind: PersistentVolumeClaim metadata: name: csi-infoscale-pvc-static spec: accessModes: ReadWriteOnce resources: requests: storage: 2Gi storageClassName: csi-infoscale-sc-prod volumeName: csi-infoscale-pv Same thing works fine on OCP. WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. Use --output=yaml|json to get the full version.