jiebi/CodeConvo huggingface dataset:
Change:
} }) <del> ginkgo.It("should run through the lifecycle of a CSIDriver", func(ctx context.Context) { </del> <ins> /* Release: v1.28 Testname: CSIDriver, lifecycle Description: Creating two CSIDrivers MUST succeed. Patching a CSIDriver MUST succeed with its new label found. Updating a CSIDriver MUST succeed with its new label found. Two CSIDrivers MUST be found when listed. Deleting the first CSIDriver MUST succeed. Deleting the second CSIDriver via deleteCollection MUST succeed. */ framework.ConformanceIt("should run through the lifecycle of a CSIDriver", func(ctx context.Context) { </ins> // Create client client := f.ClientSet.StorageV1().CSIDrivers() defaultFSGroupPolicy := storagev1.ReadWriteOnceWithFSTypeFSGroupPolicy

Discussion:
[X] test approval issue : [X] test pr : 26 May 2023 [x] two weeks soak end date : 9 June 2023 [x] test promotion pr : [x] remove endpoint from [x] End of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection. According to following APIsnoop query, there are still 3 CSIDriver endpoints that are not tested for Conformance. Using a number of existing e2e test practices a new has been created to address these 3 endpoints. The e2e logs for this test are listed below. This query shows the following csiDriver endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
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
/reopen For end of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection.
Reopened this issue. <detailsIn response to : /reopen For end of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection. 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
Change:
package genericclioptions import ( <ins> "net/http" </ins> "testing" "github.com/spf13/cobra"

Discussion:
No errors printed. Not sure. This is the same thing as , was fixed by Happened in a CI build Kubernetes version (use ): kubectl version 1.22.0 from image. Cloud provider or hardware configuration: OS (e.g: ): linux Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig cli
/triage accepted /assign
We'll need to cherry pick this to 1.22.
Looks like the cancellation was indeed from a timeout. Sean will have a fix but do you have more insight into the timeout?
The build I linked above is using a feature of GitLab Kubernetes Agent called , which allows to access Kubernetes API from a CI job. An agent is proxying requests into the cluster. When I was investigating timeouts I discovered that they happen because of in the agent. Throttling happened because kubectl was making way too many requests and the code was not caching the authentication results. After fixing this, I started to investigate why kubectl is making so many requests in the first place and discovered that the image that was used () has a read-only file system and discovery client from client-go cannot persist the discovery information to disc and hence it performs discovery 3 (!) times for a simple request. This results in 125 API calls. I tried to fix that in by caching the discovery client, but it doesn't help. The solution is to cache discovery info in memory because even if a single discovery client is used, it just discards the data and re-fetches it if it's not on disk. Please have a look at that PR.
The code that reported the error is The interface only has one function: The as a function of a appears to be a convention in most (but not all) Kubernetes .
For more context: the is implemented in the . This error message is printed when this cached discovery client encounters a timeout, and tries to cancel the request. The is wrapped by the , and it it unable to propagate the because the does not implement .
I'm experiencing this today, seeing this error on my two master nodes. The whole cluster is down. I was performing activities which were using the hard drive quite a bit. Not sure if that helps with debugging. Might be time to reboot the system hosting the node vms.

But I think I'll experiment some more being that it is a dev cluster. A reboot of each of the master nodes and things are coming back up. Worker nodes were fine.
Change:
wErr:          nil, }, { <del> name: "test even pods spread predicate - 3 nodes with maxskew=2", </del> <ins> name: "test podtopologyspread plugin - 3 nodes with maxskew=2", </ins> registerPlugins: []st.RegisterPluginFunc{ st.RegisterQueueSortPlugin(queuesort.Name, queuesort.New), st.RegisterPluginAsExtensions(

Discussion:
How to reproduce it (as minimally and precisely as possible): pre-requisites: a multi-az cluster, a deployment with 1 pod in each az. a with and . the node(s) in 1 az. the deployment's pod(s) from the cordoned az. What happened: A new pod was created and scheduled in a form that What you expected to happen: I expected that a new pod will be created and be "stuck" in status as it shouldn't have nowhere be scheduled. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ): 4.19.84-coreos Others: I created a with how I reproduce the bug
/sig scheduling
cc/
Thanks for raising this issue. I feel like it's a general timing issue - when you delete a Pod, that Pod may still exist for a very short time (in graceful deletion period), and at the same time, the controller backfills a Pod for it. So when scheduling tries to schedule the backfill Pod, it may read the cluster as: [1, 1, 1(deleting)]. To confirm this, can you try deleting the Pod using , and see if the problem goes away?
Yes sure I will try that. It sounds reasonable, thats why in the first demonstration I deleted all the pods and waited for all of them to completely disappear. Nevertheless, this is still something that I believe needs to be fixed. The pod's evaluation should take in consideration pods that are in status and don't count them as pods.
I do believe we exclude the Pods. (if not, it should be a serious regression). What concerns me is that at that moment, scheduler may treats that (deleting) Pod as running in its cache. I will try to debug into this.
Yep, this time the new pod was in status until I uncordoned the relevant nodes.
Change:
log.Fatal("Couldn't connnect to docker.") } <del> hostname, err := exec.Command("hostname", "-f").Output() if err != nil { log.Fatalf("Couldn't determine hostname: %v", err) </del> <ins> hostname := []byte(*hostnameOverride) if string(hostname) == "" { hostname, err = exec.Command("hostname", "-f").Output() if err != nil { log.Fatalf("Couldn't determine hostname: %v", err) } </ins> } my_kubelet := kubelet.Kubelet{

Discussion:
It would be great to have an easy way to run a kubernetes master/minion locally. Currently, it's not that easy to set up. We should have a convenient script to make it work.
The integration test binary is pretty close. It'd be pretty simple to glue in the kubelet to that binary. Brendan On Jun 10, 2014 2:53 PM, "Daniel Smith" wrote:
I'll take a look.
+1 for this -- especially in script form rather than a go executable.
what exactly do you mean by "script form"? Were you thinking of something like a version of cloudcfg that can be run without needing to have started up a daemon first?
Basically, what I had in mind, is a shell script that looks something like
Ah, ok. That's very similar to local-; the only difference is that everything is packaged into a single go binary. We probably will switch to using individual binaries for this when we start running our components inside docker containers.
The script just makes things more obvious how to run things for those who are looking to integrate them into non-GCE environments.
That's a good point. I'll look into this some more later.
Create a pad as follows: Name: non-persistent-redis Container image: redis Named-volum with name: cache-control Mount path: /data/redis It should launch in the pre-prod namespace and the volume MUST NOT be persistent. apiVersion: v1 kind: Pod metadata: name: non-persistent-redis namespace: pre-prod spec: containers: name: non-persistent-redis image: redis volumeMounts: name: cache-control mountPath: "/data/redis" volumes: name: cache-control emptyDir: {}

I cannot find such a service when . Same thing applies for . My cluster runs fine. cc:
Ah, good catch... everything is run as a container now, will update the documentation on where to get the logs.

When I'm accessing persistentVolumes and persistentVolumeClaims, I'm getting nil instead of empty list of items, as happening in other entities when there are no items. { "kind": "PersistentVolumeList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/persistentvolumes", "resourceVersion": "" } }
Yes, this seems like a bug. I see an empty list when I access pods: And items is nil when I access persistent volumes:
Items shouldn't be tagged with omitempty:
cc
PersistentVolumeList and PersistentVolumeClaimList appear to be the only resource types with this problem.
Please see for fix.
Change:
import ( "context" <ins> "errors" </ins> "fmt" "net" "strings"

Discussion:
At (originally ) component-base metrics exposed Registerer API for raw prometheus registration, and I took dependency in The resulting does not seem to emit the new metrics (example: ). The metrics handler should emit the registered metrics. Falling back to does work. So there is some material difference with . 24, 1.25, 1.26 GKE No response No response No response No response
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
/assign
/assign jkh52
Change:
By("getting scale subresource") scale := framework.NewStatefulSetScale(ss) <del> scaleResult := &apps.Scale{} err = c.AppsV1beta1().RESTClient().Get().AbsPath("/apis/apps/v1beta1").Namespace(ns).Resource("statefulsets").Name(ssName).SubResource("scale").Do().Into(scale) </del> <ins> scaleResult := &appsv1beta2.Scale{} err = c.AppsV1beta2().RESTClient().Get().AbsPath("/apis/apps/v1beta2").Namespace(ns).Resource("statefulsets").Name(ssName).SubResource("scale").Do().Into(scale) </ins> if err != nil { framework.Failf("Failed to get scale subresource: %v", err) }

Discussion:
What happened: There are no e2e and integration tests for statefulset scale subresource. What you expected to happen: (1) e2e test should exist BEFORE code freeze (2) integration test should exist AFTER 1.8 release branches cut Anything else we need to know?: Refer PR for more info. We should NOT remove existing e2e test.
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
/close
Change:
var k8sBinDir = flag.String("k8s-bin-dir", "", "Directory containing k8s kubelet and kube-apiserver binaries.") <ins> var buildTargets = []string{ "cmd/kubelet", "cmd/kube-apiserver", "test/e2e_node/e2e_node.test", "vendor/github.com/onsi/ginkgo/ginkgo", } </ins> func buildGo() { glog.Infof("Building k8s binaries...") k8sRoot, err := getK8sRootDir() if err != nil { glog.Fatalf("Failed to locate kubernetes root directory %v.", err) } <del> cmd := exec.Command(filepath.Join(k8sRoot, "hack/build-go.sh")) </del> <ins> cmd := exec.Command(filepath.Join(k8sRoot, "hack/build-go.sh"), buildTargets...) </ins> cmd.Stdout = os.Stdout cmd.Stderr = os.Stderr err = cmd.Run()

Discussion:
All the LoadBalancers tests It seems that for a long time IPVS and iptable implementations differ, it may be possible the test do some wrong assumptions? At this point is up to the IPVS maintainers if they want to run those tests or not, is ok if they don't have time to investigate to disable the tests, but we should not have flaky test running or we'll have a lot of noise /sig network /area ipvs /help
/sig network /area ipvs /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig network /area ipvs /help 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
Change:
defaultArguments["etcd-cafile"] = filepath.Join(cfg.CertificatesDir, kubeadmconstants.EtcdCACertName) defaultArguments["etcd-certfile"] = filepath.Join(cfg.CertificatesDir, kubeadmconstants.APIServerEtcdClientCertName) defaultArguments["etcd-keyfile"] = filepath.Join(cfg.CertificatesDir, kubeadmconstants.APIServerEtcdClientKeyName) <ins> // Apply user configurations for local etcd if cfg.Etcd.Local != nil { if value, ok := cfg.Etcd.Local.ExtraArgs["listen-client-urls"]; ok { defaultArguments["etcd-servers"] = value } } </ins> } if features.Enabled(cfg.FeatureGates, features.HighAvailability) {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When I use kubeadm to create a cluster, the specified parameter "listen-client-urls" does not work. kubeadm init --config=kube- fail with connection refuse for get http://127.0.0.1:2379 I think the element 'listen-client-urls' is unrecognized if the customized value is not equal '127.0.0.1' Here is my kube- No matter how I set the "listen-client-urls" parameter in the kube- , it is awlays be "https://127.0.0.1:2379" What you expected to happen: The parameter "listen-client-urls" can work! How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.11.2 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): CentOS Linux release 7.5.1804 (Core) Kernel (e.g. ): Linux kube-dev 3.10.0-862.el7.x8664 SMP Fri Apr 20 16:44:24 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: Others:
/sig cluster-lifecycle
/lifecycle active
kubeadm 1.13 has set the default value to Default route transits interface ip address instead of loopback ip
Change:
# - centos 7 # - debian jessie <del> # RHEL os detection cat /etc/*-release | grep "ID="rhel"" OS_RHEL=$? </del> # On a systemd environment, enable cpu and memory accounting for all processes by default. if [ -d /etc/systemd ]; then cat <<EOF >kubernetes-accounting.conf

Discussion:
in e2enode test curls and directly pipes to shell: The issue is that this may present a supply chain security risk, as we are directly executing the script from I would instead expect one of the following: host includes docker already via it's OS image script is checked into this repo and version controlled script is at least verified to be unchanged via hash Running anything from - , such as: No response All GCP (kind of) N/A N/A N/A N/A
/sig node
that's some pretty old bash, I don't think we're actually using this in CI, probably that codepath can just be dropped, but up to the SIG node folks.
/triage accepted /priority backlog /assign
the script is being referred from the docs: I think the safest bet is to simply remove the docker installation part.
Change:
} return schema.GroupVersion{} } <del> func hasZeroLimitedNominalConcurrencyShares(obj *flowcontrol.PriorityLevelConfiguration) bool { return obj != nil && obj.Spec.Limited != nil && obj.Spec.Limited.NominalConcurrencyShares == 0 } </del>

Discussion:
In 1.30, Priority and Fairness should allow a zero value, either via v1 or v1beta3 (with the roundtrip annotation) in create and update requests See:
/sig api-machinery /cc /assign
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accpted 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
/triage accepted
Change:
import ( "fmt" <ins> "sort" "github.com/golang/glog" </ins> cadvisorapi "github.com/google/cadvisor/info/v1" "k8s.io/kubernetes/pkg/kubelet/cm/cpuset" )

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: CPU Manager uses topology from cAdvisor which uses which is different from in terms of coreID's. assigns coreID's in unique manner (platform-wise) whereas has coreID's from CPU registers which are unique only on socket level. This causes some unexpected cpu assignment on platforms with more than one socket. All tests written all "false positive" Example output: From What you expected to happen: Fix either by changing the way CPU manger sees topology (use ) or redesign CPU Manager to handle coreID's as socket only unique How to reproduce it (as minimally and precisely as possible): kubelet on dual socket node G pod that requests 2 cores pod gets 2 cores on different sockets
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig node
Change:
reason = pod.Status.Reason } <del> // If the Pod carries {type:PodScheduled, reason:WaitingForGates}, set reason to 'SchedulingGated'. </del> <ins> // If the Pod carries {type:PodScheduled, reason:SchedulingGated}, set reason to 'SchedulingGated'. </ins> for _, condition := range pod.Status.Conditions { if condition.Type == api.PodScheduled && condition.Reason == apiv1.PodReasonSchedulingGated { reason = apiv1.PodReasonSchedulingGated

Discussion:
<img width="844" alt="image" src="" <img width="942" alt="image" src="" Here are some incorrect comments and function name about SchedulingGated Comments and function names need to be changed to SchedulingGated nothing No response <details</details<details</details<details</details<details</details<details</details<details</details
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
/assign
/sig scheduling
/remove-kind bug /kind cleanup
Change:
return probe.Failure, err.Error(), nil } req.Header = headers <ins> if headers.Get("Host") != "" { req.Host = headers.Get("Host") } </ins> res, err := client.Do(req) if err != nil { // Convert errors into failures to catch timeouts.

Discussion:
I noticed that httpHeaders were to the httpGet probe in to Sadly the httpHeaders addition to the httpGet probe does function correctly for all headers except the header. I think this must be to do with the way make a special case of the Host header . I have some code I used to debug the issue that I can share if needed.
Sigh, letting you set Host was the entire point of providing that option.
Does the host header work in probes now? I have been browsing the issues but can not tell, as I am having trouble with it in my setup.
my fix should be in kubernetes 1.2.3+ I found some code that exercises the issue... could you try this on your cluster I cannot reproduce in the environment I have to hand that is running k8s 1.7
Change:
for nsn, count := range newEndpoints { if hcs.services[nsn] == nil { <del> klog.V(3).InfoS("Not saving endpoints for unknown healthcheck", "service", nsn) </del> continue } klog.V(3).InfoS("Reporting endpoints for healthcheck", "endpointCount", count, "service", nsn)

Discussion:
We are using Azure AKS V1.20.7 and the service type in production environment is ClusterIP. In Kube-proxy logs, continuously I see the below printed line. "Not saving endpoints for unknown healthcheck" ] Not saving endpoints for unknown healthcheck It may increase Syncing time I believe. Kindly assist. It should not print below line in kube-proxy logs. "Not saving endpoints for unknown healthcheck" ] Not saving endpoints for unknown healthcheck Service is of type - ClusterIP Validate kube-proxy logs in kube-system No response Azure AKS 1.20.7 Azure AKS <details</details<details</details<details</details<details</details
/sig network
/assign
/cc
I think that this is a duplicate of It also has a PR to fix it
/triage accepted I think we should remove that log line, is not meaningful
Just confirming, should I make a PR removing log line.
Thank you It won’t print that line in next k8s version ? Like 1.21.7? Any specific version?
I have doubts that this qualifies for backporting, because it is only happening if the log level verbosity is 3 or higher, a verbosity level of 2 use to be the default IIRC. Also, It's not impacting any functionality. Not backporting this change means that this only be present in current version 1.24, for previous versions people can configure the kube-proxy loglevel verbosity to 2 or lower, and it will not log this messge. is there any way users can define the kube-proxy verbosity level to 2? any inconvenient for doing that?
For AKS (managed cluster), I just checked and the default log verbosity configured is 3 to enable debug logging. For self-managed Kubernetes cluster, I think users have control over the log verbosity but for managed by default verbose logging is enabled? Have we backported any similar logging changes before?
WDYT about backporting this patch? ^^^
looks like is a log part, sgtm to backport
would you like to take care of the backports?
Do you want to open the PRs for backport? If not, lmk and I can open them.
Open PRs for backport: