jiebi/CodeConvo huggingface dataset:
Change:
creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults <del> name: system:aws-cloud-provider rules: - apiGroups: - "" resources: - nodes verbs: - get - patch - apiGroups: - "" resources: - events verbs: - create - patch - update - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults </del> name: system:basic-user rules: - apiGroups:

Discussion:
As of , all Kubernetes clusters with RBAC bootstrap roles for AWS, regardless of whether they are running on AWS. The hardcoded RBAC bootstrap policy should only include roles that are used by all clusters, regardless of addons, configuration, or cloud provider. The ClusterRole(Binding)s should be removed from the bootstrap policy, and instead configured by the provisioning tools. /sig aws /sig cloud-provider /sig auth
/assign I can help do it. :)
Change:
kind: %s metadata: name: %s <del> finalizers: - test-finalizer </del> spec: foo: foo1 cronSpec: "* * * * */5"

Discussion:
After running k8s conformance testing on kubernetes v1.27, we have leftover custom resources of the format that should not exist. For example) Basic test instructions: We use the latest official kubernetes kubekins image: We extract kubetest binary from kubekins latest-master docker image. We run serial conformance tests as follows. We also run parallel conformance tests as follows.
/sig api-machinery
The following script is used to cleanup the leftover CRDs:
/triage accepted /assign /cc
/area conformance
/sig architecture
Change:
# List a single replication controller with specified NAME in ps output format. kubectl get replicationcontroller web <ins> # List deployments in JSON output format, in the "v1" version of the "apps" API group: kubectl get deployments.v1.apps -o json </ins> # List a single pod in JSON output format. kubectl get -o json pod web-pod-13je7

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature /sig cli What happened: I have two custom resources in my cluster called Cluster, and couldn't figure out how to ask for one or the other. was of no help, and various Google searches for things like "kubectl apigroup" or "kubectl crd" revealed nothing of use. Worse, some bugs that came up like suggested that the syntax was , which produced entirely incorrect output (e.g. results in . Eventually, I stumbled by accident on the correct way to do it, which is to do and then , where is the name of the custom resource exactly as listed in the output of . I still don't know how to request a specific API version using this syntax, if that is even possible. What you expected to happen: I expected to document how to query custom resources, given that they're increasingly central to running production quality clusters with various operators. Failing that, I expected the k8s website to have documentation on querying custom resources that is discoverable via Google search. How to reproduce it (as minimally and precisely as possible): Install something that uses custom resources (e.g. Calico in k8s datastore mode, Rook), and try to one of the custom resources by precise name (e.g. assume that there are multiple objects defined by different CRDs, so you can't just , you have to be more precise). Environment: Kubernetes version (use ): 1.10.2 client+cserver
Opened with examples
Change:
requestScope = "resource" operationSuffix = operationSuffix + "WithPath" } <ins> if strings.Index(action.Path, "/{name}") != -1 || action.Verb == "POST" { requestScope = "resource" } </ins> if action.AllNamespaces { requestScope = "cluster" operationSuffix = operationSuffix + "ForAllNamespaces"

Discussion:
<!-- 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: While I was watching grafana for a single run, I noticed that GET requests are reported as LIST requests, e.g. grafana shows ~1K QPS for LIST of pods ! while kube-apiserver's logs show: (there are no pod lists that time). I'm not sure if this is intended change to metrics reporting (kind of unexpected to be honest), but this definitely affects way our scalability tests validate latency metrics: We do not validate GET API call latency at all Validation for LIST requests is also affected, as usually GET API calls are way cheaper than LIST requests, so grouping GET-LISTs and LIST-LISTs together lowers p99 for LISTs. Also perf-dash shows that GET requests simply disappeared at some point: http://perf- ! What you expected to happen: GET requests should be reported with verb=GET in apiserverrequest_total metric. 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:

FYI
I managed to narrow the issue by bisecting the runs of which runs load tests using master k/k every 1 hour. This is the last test run that had GETs reported correctly: This is the first test run that has no GETs reported: Looking at the k/k repo commits' hashes inside artifacts in both runs and at what happened between each of them it looks as if might be the culprit.
From the former run's artifacts: This is (among others) what we miss in the latter run - this is understandable from the point of view of this if condition: Why did the reported GETs have as the scope instead of in the first place, however??
It seems that our handing is incorrect: vs Or my understanding of it was incorrect.

It seems that the semantic is: cluster - for cluster-scope requests namespace - for namespace-scoped requests request - for subresources I think the assumption in the monitoring path was: cluster - for cluster-scope requests namespace - for namespace-scope requests requests - for requests touching a single resource (not necessary subresource) I'm not 100% sure which semantic we should use - based on the finding we should fix one or the other place...
cc There should probably be a unit test mapping URL paths to the expected label values.
is opened to fix that.
/triage accepted
Change:
return s.cidr } <del> func (s *runtimeState) setInitError(err error) { s.Lock() defer s.Unlock() s.initError = err } </del> func (s *runtimeState) runtimeErrors() []string { s.RLock() defer s.RUnlock() var ret []string <del> if s.initError != nil { ret = append(ret, s.initError.Error()) } </del> if !s.lastBaseRuntimeSync.Add(s.baseRuntimeSyncThreshold).After(time.Now()) { ret = append(ret, "container runtime is down") }

Discussion:
In our k8s cluster, a node's status is NotReady, and we checked the kubelet's log, that repeated "skipping pod synchronization" every 5 minutes: I found the code where printing those logs, in the syscLoop function. if runtimeState has error, kubelet will get into endless loop, and will print "skipping pod synchronization" every five minutes. In our case, the node got an error when startup, in the function initializeModules, which called our cloud provider to get node info, because the call returned an error, kubelet set the error to runtimeState, and ran syscLoop next, going to endless loop. I think there is a problem here: Startup function "initializeModules" encountered an error like "failed get node info", which is rarely, kubelet should exit its process and it will be restarted by systemd successfully. Restarting kubelet is more reaonable than printing error log in the endless loop, Restarting event can be mornitored easily, but the admin can hardly detect the endless loop.
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
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
/remove-lifecycle rotten
Change:
v1 "k8s.io/api/core/v1" kubeletdevicepluginv1beta1 "k8s.io/kubelet/pkg/apis/deviceplugin/v1beta1" e2epod "k8s.io/kubernetes/test/e2e/framework/pod" <ins> "k8s.io/kubernetes/test/e2e/nodefeature" </ins> imageutils "k8s.io/kubernetes/test/utils/image" admissionapi "k8s.io/pod-security-admission/api" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" <del> "k8s.io/kubernetes/pkg/features" </del> "k8s.io/kubernetes/test/e2e/framework" "k8s.io/kubernetes/test/e2e_node/testdeviceplugin" ) <del> var _ = SIGDescribe("Device Plugin Failures Pod Status:", framework.WithFeatureGate(features.ResourceHealthStatus), func() { </del> <ins> var _ = SIGDescribe("Device Plugin Failures Pod Status", nodefeature.ResourceHealthStatus, func() { </ins> f := framework.NewDefaultFramework("device-plugin-failures") f.NamespacePodSecurityLevel = admissionapi.LevelPrivileged

Discussion:
July 24th. I think there is some suble way the test is named. Test is covered by and that works. I think this is mainly an issue where this test should not be run with these jobs. /sig node
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
what is the correct way to label a job now? This is apparently wrong and causing the job to be picked up in the unlabeled name.
You still need to have a corresponding feature in because, as you noticed, there are jobs which don't support skipping based on the feature gate.
I created an issue in test-infra. once all tasks are completed, it's okay only to use framework.WithFeatureGate. There may be a lot of jobs that need to be updated. for now, you have to add a feature label or modify all the failing jobs.
/assign
xref
Change:
}, } for _, tt := range tests { <ins> t.Run(tt.name+" table", func(t *testing.T) { table := &metav1beta1.Table{} meta.EachListItem(tt.obj, func(item runtime.Object) error { table.Rows = append(table.Rows, metav1beta1.TableRow{ Object: runtime.RawExtension{Object: toUnstructuredOrDie(encodeOrDie(item))}, }) return nil }) expectedTable := &metav1beta1.Table{} meta.EachListItem(tt.sort, func(item runtime.Object) error { expectedTable.Rows = append(expectedTable.Rows, metav1beta1.TableRow{ Object: runtime.RawExtension{Object: toUnstructuredOrDie(encodeOrDie(item))}, }) return nil }) sorter, err := NewTableSorter(table, tt.field) if err == nil { err = sorter.Sort() } if err != nil { if len(tt.expectedErr) > 0 { if strings.Contains(err.Error(), tt.expectedErr) { return } t.Fatalf("%s: expected error containing: %q, got: "%v"", tt.name, tt.expectedErr, err) } t.Fatalf("%s: unexpected error: %v", tt.name, err) } if len(tt.expectedErr) > 0 { t.Fatalf("%s: expected error containing: %q, got none", tt.name, tt.expectedErr) } if !reflect.DeepEqual(table, expectedTable) { t.Errorf("[%s]nexpected/saw:n%s", tt.name, diff.ObjectReflectDiff(expectedTable, table)) } }) </ins> t.Run(tt.name, func(t *testing.T) { sort := &SortingPrinter{SortField: tt.field, Decoder: scheme.Codecs.UniversalDecoder()} err := sort.sortObj(tt.obj)

Discussion:
<!-- 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!--What happened: seems to have regressed in v1.13.0 and no longer sorts by creation timestamp. What you expected to happen: should sort by creation timestamp. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: N/A Environment: Kubernetes version (use ): <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
/assign
bisected to () /assign
opened to fix
/assign
Change:
admissionregistrationv1 "k8s.io/api/admissionregistration/v1" appsv1 "k8s.io/api/apps/v1" <del> coordinationv1 "k8s.io/api/coordination/v1" </del> v1 "k8s.io/api/core/v1" rbacv1 "k8s.io/api/rbac/v1" apiextensionsv1 "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"

Discussion:
Kubernetes e2e suite: [It] [sig-api-machinery] AdmissionWebhook [Privileged:ClusterAdmin] should reject everything except leases The job was run on Aug 5th. I had a PR fixing typos in comments of kubelet source code. It is not related to api-machinery ipv6 but the test failed. The re-test passed. No response No response It seems the test is recently . /sig api-machinery /sig testing
It is failing considerably , it seems it fails to connect to the webhook that matches the time the test was I don't fully understand the test but it seems that is interacting with the cluster, I don't have clear if the deny policy affects everything and this is causing the race with the pod that implements the webhook /priority critical-urgent /release blocker /cc
/assign
cc
Debugged with Joe offline, paste for reference click open stderr on the failure to get the timeline
still failing after merge of
/triage accepted
It's suspicious that of all the admission webhook tests that start up a webhook pod, this is the one that flakes. I'll look more closely.
Looks like the webhook in this test may be configured to deny requests except leases globally in the cluster once enabled., which might create a race where, if the webhook is registered first , the controller setting up the webhook pod is denied requests by the webhook. I'll scope the webhook matching to the test namespace per offline suggestion.
Please let me know if I can be of help debugging this.Have free cycle and would like to contribute.
/assign
I can still see references to the expression that gives error Example run: Could you help confirm that the tests are completely removed? Thank you. cc
I think this is another test that is impacting the rest of the tests. Probably because the tests are running in parrallel. We might want to scope things down. Currently working on a fix.
/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
this is a new bug, please review all the test that were and verify they are scoped to the custom created namespaces by the test framework, and if not, please tag them as cc:
/cc
I assume this could be closed with merged? /cc
Looks like the exact flak as reported in this issue has been resolved. /close
Closing this issue. <detailsIn response to : Looks like the exact flak as reported in this issue has been resolved. /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
Change:
cl = client.NewOrDie(&restclient.Config{Host: *apiServerAddress}) }) <del> Describe("image conformance blackbox test", func() { </del> <ins> Describe("[FLAKY] image conformance blackbox test", func() { </ins> Context("when testing images that exist", func() { var conformImages []ConformanceImage BeforeEach(func() {

Discussion:
As of now node e2e requires all the tests to pass. There are tests like the container conformance tests which have been flaky in the past - , , We need ability to mark certain tests as flaky and not run them as part of merge queue.
Ginkgo flags makes it possible to skip tests. We can use a prefix to not run flaky tests in our existing jenkins CIs.
Closing via
Change:
// Verify that disk shows up in node 0's volumeInUse list framework.ExpectNoError(waitForPDInVolumesInUse(nodeClient, diskName, host0Name, nodeStatusTimeout, true /* should exist*/)) <del> output, err := exec.Command("gcloud", "compute", "instances", "list", "--project="+framework.TestContext.CloudConfig.ProjectID).CombinedOutput() </del> <ins> gceCloud, err := framework.GetGCECloud() framework.ExpectNoError(err, fmt.Sprintf("Unable to create gcloud client err=%v", err)) output, err := gceCloud.ListInstanceNames(framework.TestContext.CloudConfig.ProjectID, framework.TestContext.CloudConfig.Zone) </ins> framework.ExpectNoError(err, fmt.Sprintf("Unable to get list of node instances err=%v output=%s", err, output)) Expect(true, strings.Contains(string(output), string(host0Name))) By("deleting host0") <ins> resp, err := gceCloud.DeleteInstance(framework.TestContext.CloudConfig.ProjectID, framework.TestContext.CloudConfig.Zone, string(host0Name)) framework.ExpectNoError(err, fmt.Sprintf("Failed to delete host0pod: err=%v response=%#v", err, resp)) </ins> <del> output, err = exec.Command("gcloud", "compute", "instances", "delete", string(host0Name), "--project="+framework.TestContext.CloudConfig.ProjectID, "--zone="+framework.TestContext.CloudConfig.Zone).CombinedOutput() framework.ExpectNoError(err, fmt.Sprintf("Failed to delete host0pod: err=%v output=%s", err, output)) output, err = exec.Command("gcloud", "compute", "instances", "list", "--project="+framework.TestContext.CloudConfig.ProjectID).CombinedOutput() </del> <ins> output, err = gceCloud.ListInstanceNames(framework.TestContext.CloudConfig.ProjectID, framework.TestContext.CloudConfig.Zone) </ins> framework.ExpectNoError(err, fmt.Sprintf("Unable to get list of node instances err=%v output=%s", err, output)) Expect(false, strings.Contains(string(output), string(host0Name)))

Discussion:
<!-- 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 bug /sig storage What happened: Offshoot of . Let's change the tests to use the programmatic API instead of gcloud CLI.
Just confirming that this issue is referring only to the 3 gcloud CLI calls in
yup
PR:
Change:
framework.Failf("timeout in waiting for the owner to be deleted: %v", err) } <del> // Wait 30s and ensure the dependent is not deleted. ginkgo.By("wait for 30 seconds to see if the garbage collector mistakenly deletes the dependent crd") if err := wait.PollWithContext(ctx, 5*time.Second, 30*time.Second+gcInformerResyncRetryTimeout, func(ctx context.Context) (bool, error) { _, err := resourceClient.Get(ctx, dependentName, metav1.GetOptions{}) return false, err }); err != nil && !wait.Interrupted(err) { framework.Failf("failed to ensure the dependent is not deleted: %v", err) } </del> <ins> timeout := 30*time.Second + gcInformerResyncRetryTimeout ginkgo.By(fmt.Sprintf("wait for %s to see if the garbage collector mistakenly deletes the dependent crdn", timeout)) gomega.Consistently(ctx, framework.HandleRetry(func(ctx context.Context) (*unstructured.Unstructured, error) { return resourceClient.Get(ctx, dependentName, metav1.GetOptions{}) })).WithTimeout(timeout).WithPolling(5 * time.Second).ShouldNot(gomega.BeNil()) </ins> }) ginkgo.It("should delete jobs and pods created by cronjob", func(ctx context.Context) {

Discussion:
Kubernetes e2e suite: [It] [sig-api-machinery] Garbage collector should support orphan deletion of custom resources [sig-api-machinery] As stated in When I replace PollWithContext with PollUntilContextTimeout in the test directory, the CI always returns the following error: The testcase can pass consistently. In the code where the error occurs, replace PollWithContext with PollUntilContextTimeout No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery testing
/triage accepted
Change:
errBadCertificate    = "Get .*: remote error: tls: bad certificate" errNoConfiguration   = "invalid configuration: no configuration has been provided" errMissingCertPath   = "invalid configuration: unable to read %s %s for %s due to open %s: .*" <del> errSignedByUnknownCA = "Get .*: x509: certificate signed by unknown authority" </del> <ins> errSignedByUnknownCA = "Get .*: x509: .*(unknown authority|not standards compliant|not trusted)" </ins> ) var (

Discussion:
unit tests since switching to go1.18 No response No response Weirdly, the test is passing in CI () and failing locally /sig api-machinery auth testing
seems related Jordan, are you using mac ?
yes, though the description in that issue seems to be not just test-only changes to the errors received from invalid certificates (which is what I saw), but actual certificates that previously validated
marking as release blocker until it is determined that go1.18 is not rejecting valid certificates
this needs an assignee and a reproducer we can file as an upstream issue for golang to ask why previously valid certificates now fail validation
marking critical until root-caused and determined whether this is prod-impacting, since (in my opinion) this should block rc0
On linux it works fine: on MacOS, it fails:
Looks like the change in golang that broke the scenario was:
if the only impact is a different failure message on an already-invalid certificate, I don't care and we can update the test to accept either message is what makes me wonder what previously-accepted certificates are now failing
reproducer test case here. this one has no issues under go 1.17 and fails with go 1.18 (stripped down version of ) : :
the new error message is minted here: i suspect it is related to: So essentially this seems to be something that may hit in our case. right?
yeah, if this is scoped to just darwin clients, and only ones using system roots, that greatly narrows the impact
Asked on gophers slack -
xref:
opened to tolerate the additional errors discussion in indicates the tightened validation is very bounded (darwin-only, so clients-only, system roots only), and certificates issued by public CAs would be expected to pass this validation dropping release-blocking label and priority to important-soon, but should still make it into 1.24 to make unit tests pass locally
Change:
client.BindClientConfigFlags(fs, &s.ClientConfig) fs.StringVar(&s.AlgorithmProvider, "algorithm_provider", s.AlgorithmProvider, "The scheduling algorithm provider to use") fs.StringVar(&s.PolicyConfigFile, "policy_config_file", s.PolicyConfigFile, "File with scheduler policy configuration") <del> fs.BoolVar(&s.EnableProfiling, "profiling", false, "Enable profiling via web interface host:port/debug/pprof/") </del> <ins> fs.BoolVar(&s.EnableProfiling, "profiling", true, "Enable profiling via web interface host:port/debug/pprof/") </ins> } // Run runs the specified SchedulerServer.  This should never exit.

Discussion:
goroutine 11 [running]: net/http.(ServeMux).Handle(0xc20800a8a0, 0x9e9490, 0xd, 0x7f7d12f190a0, 0xb0e7c0) +0x244 net/http.(ServeMux).HandleFunc(0xc20800a8a0, 0x9e9490, 0xd, 0xb0e7c0) +0x6d net/http.HandleFunc(0x9e9490, 0xd, 0xb0e7c0) +0x48 ·001() +0x58 created by (*SchedulerServer).Run +0x1c7
cc