jiebi/CodeConvo huggingface dataset:
Change:
if groupVersion == nil { return fmt.Errorf("apiVersion not set") } <ins> if _, ok := groupVersion.(string); !ok { return fmt.Errorf("apiVersion isn't string type") } </ins> kind := fields["kind"] if kind == nil { return fmt.Errorf("kind not set") } <ins> if _, ok := kind.(string); !ok { return fmt.Errorf("kind isn't string type") } if strings.HasSuffix(kind.(string), "List") { return errors.NewAggregate(s.validateList(fields)) } </ins> version := apiutil.GetVersion(groupVersion.(string)) allErrs := s.ValidateObject(obj, "", version+"."+kind.(string)) if len(allErrs) == 1 {

Discussion:
Using kubectl create with a list no longer works. We get the output:
In kubernetes 1.0 with a List would create all items in the List.
Test data to duplicate the problem:
CC
FYI in case you run into this.
Another feature that needs a test.
the swagger spec may only include object definitions that are registered as API request/response types... since isn't actually submitted to the server (that I know of), that's probably why it didn't get included. Enabling validation by default () probably exposed the bug with a List not being able to validate
We need to make validation on List work. We should test multiple resources w/o List as well.
Naive question: Could we just call Schema() after Flatten() but before Do()?
Hmm. No, validation isn't actually called there.
Each input-source visitor (URLVisitor, FileVisitor, StreamVisitor) has its own call to ValidateSchema. We need to validate before decoding, but we don't unpack the list until after decoding.
We could do something similar to FlattenListVisitor in ValidateSchema: But that's pretty ugly.
Do you have time to take a look at what the most straightforward solution/workaround is for this? Longer-term we should maybe push this into the json decoder, as proposed here:
The simplest thing might be to add List to the swaggerapi models list… I was looking into that yesterday and got sidetracked
I thought about adding List, but it didn't look like the validator would recurse into the individual resource models, hence the need to special-case List.
Nobody is working on this at the moment, if you'd like to take a look.
OK, I will take a look.
If add List to the swaggerapi, I think it need to add a new api . If we post request to to handler the List, need to unpack the list in the server. Or just add an "empty" api only list the List kind ? I think that might be a little strange all above. Please correct me.
I recommended not adding List to the swagger. I don't think it would help. I think we need to detect the case of a List and extract the resources within, similar to FlattenListVisitor.
I agree. I think doing something similar to FlattenListVisitor in ValidateSchema maybe a little ugly. But it's straightforward.
Change:
killed and restarted incrementing restart count to 1. release: v1.9 file: test/e2e/common/node/container_probe.go <ins> - testname: Pod liveness probe, using grpc call, failure codename: '[sig-node] Probing container should be restarted with a GRPC liveness probe [NodeConformance] [Conformance]' description: A Pod is created with liveness probe on grpc service. Liveness probe on this endpoint should fail because of wrong probe port. When liveness probe does  fail then the restart count should +1. release: v1.23 file: test/e2e/common/node/container_probe.go </ins> - testname: Pod liveness probe, using local file, restart codename: '[sig-node] Probing container should be restarted with a exec "cat /tmp/health" liveness probe [NodeConformance] [Conformance]'

Discussion:
Instructions: Tests in : should not be restarted with a GRPC liveness probe should be restarted with a GRPC liveness probe /sig node /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue KEP:
This request has been marked as suitable for new contributors. 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 : Instructions: Tests in : /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue 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
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Instructions: Tests in : /kind cleanup /priority important-soon /area tests /help-wanted /good-first-issue 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 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
/assign
/assign
Hi, I want to take this
Change:
utilnet "k8s.io/apimachinery/pkg/util/net" "k8s.io/kubernetes/pkg/probe" <ins> "k8s.io/kubernetes/pkg/version" </ins> "github.com/golang/glog" )

Discussion:
Grabbed tcpdump of a readiness probe - the src ip was the bridge address (10.244.1.1), but apart from this, there is no identifying information in the HTTP request that this is a Kubernetes daemon requesting readiness checks - this might help QoS/priority assignment by the container application.
IIUC, you mean we should add a better when kubernetes daemon request a readiness check to identify this request comes from kubernetes daemon?
Yes, we should override the default net/http user-agent with our own. Better usability for users and we have no future upgrade hazards if users start hardcoding and expecting this default User-Agent string in their analytic tools.
Any news about this one? It would be nice! I've this little hack in my nginx configuration (in order to not be spamed by health check in logs) :)
This can probably be closed now that probes have support.
Change:
} func CreateEssentialAddons(cfg *kubeadmapi.MasterConfiguration, client *clientset.Clientset) error { <del> arches := [3]string{"amd64", "arm", "arm64"} for _, arch := range arches { kubeProxyDaemonSet := NewDaemonSet(kubeProxy+"-"+arch, createKubeProxyPodSpec(cfg, arch)) SetMasterTaintTolerations(&kubeProxyDaemonSet.Spec.Template.ObjectMeta) </del> <ins> kubeProxyDaemonSet := NewDaemonSet(kubeProxy, createKubeProxyPodSpec(cfg)) SetMasterTaintTolerations(&kubeProxyDaemonSet.Spec.Template.ObjectMeta) SetNodeAffinity(&kubeProxyDaemonSet.Spec.Template.ObjectMeta, NativeArchitectureNodeAffinity()) </ins> <del> if _, err := client.Extensions().DaemonSets(api.NamespaceSystem).Create(kubeProxyDaemonSet); err != nil { return fmt.Errorf("<master/addons> failed creating essential kube-proxy addon [%v]", err) } </del> <ins> if _, err := client.Extensions().DaemonSets(api.NamespaceSystem).Create(kubeProxyDaemonSet); err != nil { return fmt.Errorf("<master/addons> failed creating essential kube-proxy addon [%v]", err) </ins> } fmt.Println("<master/addons> created essential addon: kube-proxy") kubeDNSDeployment := NewDeployment("kube-dns", 1, createKubeDNSPodSpec(cfg)) SetMasterTaintTolerations(&kubeDNSDeployment.Spec.Template.ObjectMeta) <ins> SetNodeAffinity(&kubeDNSDeployment.Spec.Template.ObjectMeta, NativeArchitectureNodeAffinity()) </ins> if _, err := client.Extensions().Deployments(api.NamespaceSystem).Create(kubeDNSDeployment); err != nil { return fmt.Errorf("<master/addons> failed creating essential kube-dns addon [%v]", err)

Discussion:
Right now we create 3 daemonsets for in , but will only give use image names for , so this feature is broken. We should only deploy one daemon set for the native architecture, but ensure it has the right label selectors, so we don't try to run pods on nodes of different architecture. We should also make sure all addons have architecture labels, and not just . If user is building heterogeneous clusters, the will need to take about deploying addons for additional architectures, we shouldn't pre-deploy multiple things knowing that they will most likely remain unschedulable.
I have the same issue as well. I tried to create a cluster with x86 (Intel NUC) and arm (Raspberry-Pi) and I see that the kube-proxy is crashing. Here's the log entry from kube-proxy Logs from kube-proxy exec user process caused "exec format error" Attached is the kube-proxy yaml file. I see that its picking up arm image Don't know how to fix this.
Change:
// GetLoadBalancerName retrieves the name of the LoadBalancer. func (cs *CSCloud) GetLoadBalancerName(ctx context.Context, clusterName string, service *v1.Service) string { <del> return cs.GetLoadBalancerName(ctx, clusterName, service) </del> <ins> return cloudprovider.DefaultLoadBalancerName(service) </ins> } // getLoadBalancer retrieves the IP address and ID and all the existing rules it can find.

Discussion:
/kind bug /sig release Such as:
Cool issue. /assign
I see the code in was pushed by you. I don't understand what Intercept() does. Do you think there is an Infinite recursive call?
Chaos client isn’t used anywhere, and we need to remove it soon.
Ok, I can help remove it.
But there are also one place using it. How to deal with it? Delete it directly? Or something we need to do?
Has never been anything other than experimental and was not used in practice. We can remove it and it’s flag from kubelet as it was experimental. are we deprecating experimental flags for one release or can we just remove?
Change:
env: # Defaults, used if no overrides are found in fluentd-gcp-scaling-policy - name: CPU_REQUEST <del> value: 100m </del> <ins> value: 10m </ins> - name: MEMORY_REQUEST value: 200Mi - name: CPU_LIMIT

Discussion:
master-blocking: ! 2023-09-04 01:09:55 +0000 UTC No response /sig scheduling
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
most of the failures are not the scheduling test. it's
I guess not related to sig-scheduling since pods are created in kube-system? (supplement: the test code lastest changed was 2 months ago for library deprecation).
so, based on lubomir's comment the problem seem to be the fluentd pods
Sep 7 05:02:41.051: INFO: fluentd-gcp-v3.2.0-zkkj2 Pending [{PodScheduled False 0001-01-01 00:00:00 +0000 UTC 2023-09-07 04:51:10 +0000 UTC Unschedulable 0/4 nodes are available: 1 Insufficient cpu. preemption: 0/4 nodes are available: 1 No preemption victims found for incoming pod, 3 node(s) didn't match Pod's node affinity/selector.}]
the tests are a red herring, the problem is the job , can you please retitle to reflect it?
/remove-sig scheduling /sig cloud-provider
it fails to be scheduled in the master vm because of lack of cpu
The master vm only has 1 cpu, but I can't understand why it started to fail
Looks like this is passing now
Change:
# agnhost: bump this one first - name: "agnhost" <del> version: "2.30" </del> <ins> version: "2.31" </ins> refPaths: - path: test/images/agnhost/VERSION match: d.d

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 --e2e test fails with ECDSA Service Account key e2e test to succeed with ECDSA Service Account key Use ECDSA key for the service account key. Logs from the started test container: library defaults to by default as the only supported method while should be explicitly: Relevant code: On the API server side: Kubernetes version (use ): 1.21.0-rc.0 Cloud provider or hardware configuration: OS (e.g: ): Talos Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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
/sig testing
Changing the service account key type to RSA fixes the test:
this is a problem for us, as this test is part of test suite, and it fails with 1.21-rc.0 e2e tests
SIG Auth own their test cases (it's tagged in the test name), SIG Architecture own conformance. Testing owns the frameworks, CI, tooling, etc. EDIT: just clarifying and making sure the right people see it. I raised this to the conformance work group.
/assign /priority critical-urgent /milestone v1.21 because this is in the conformance suite, it must not restrict valid+supported cluster configurations
/reopen the image needs to be promoted and bumped in the e2e test
Reopened this issue. <detailsIn response to : /reopen the image needs to be promoted and bumped in the e2e test 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
promote image PR:
I believe with merged this can be closed as all the fixes were done and backported to 1.21
Thanks!
Change:
) func GetVersion(w io.Writer, kubeClient client.Interface) { <ins> GetClientVersion(w) </ins> serverVersion, err := kubeClient.ServerVersion() if err != nil { fmt.Printf("Couldn't read version from server: %vn", err) os.Exit(1) } <del> GetClientVersion(w) </del> fmt.Fprintf(w, "Server Version: %#vn", *serverVersion) }

Discussion:
We should at least print the local client version before we try to create a server client for version checking.
+1. It took me quite a while to figure out that kubectl version -c was the magic incantation to only print the client version.
Sorry, didn't realize it was assigned until after I had the PR ready :P If you also had something ready feel free to ignore mine.
Change:
// Filter is a test function that returns an error or nil, depending on the // value of "failFilter". func (fp *FilterPlugin) Filter(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeInfo *framework.NodeInfo) *framework.Status { <del> fp.numFilterCalled++ </del> <ins> atomic.AddInt32(&fp.numFilterCalled, 1) </ins> if fp.failFilter { return framework.NewStatus(framework.Error, fmt.Sprintf("injecting failure for pod %v", pod.Name))

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: integration-master Which test(s) are flaking: TestPostFilterPlugin Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/sig testing
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
/sig scheduling /remove-sig testing
/assign
Change:
} return &m, nil } <ins> func atomicWriteFile(name string, data []byte, perm os.FileMode) error { tmp := name + ".tmp" if err := os.WriteFile(tmp, data, perm); err != nil { return err } return os.Rename(tmp, name) } </ins>

Discussion:
ci-kubernetes-integration-master --- FAIL: TestMultiWebhookAuthzConfig (9.23s) (03-20) I cannot search for previous flake. updated recently /sig auth /cc
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
Updated the description, the actual cause of the flake is an unexpected change in the file reload timestamp metric
interestingly, doesn't show any failures of this test for this reason (there are a few failures on a PR that broke a bunch of integration tests for a different reason)
Fix open in , switched the file write to an atomic write
No flake after 03-29. Thanks.
Change:
cl.Step(time.Millisecond) q.flushBackoffQCompleted() // Still in backoff queue after an early flush. <ins> q.lock.RLock() </ins> if _, ok, _ := q.podBackoffQ.Get(podInfo); !ok { t.Errorf("pod %v is not in the backoff queue", podID) } <ins> q.lock.RUnlock() </ins> // Moved out of the backoff queue after timeout. cl.Step(backoff) q.flushBackoffQCompleted() <ins> q.lock.RLock() </ins> if _, ok, _ := q.podBackoffQ.Get(podInfo); ok { t.Errorf("pod %v is still in the backoff queue", podID) } <ins> q.lock.RUnlock() </ins> }) } }

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: pkg/scheduler/internal/queue Testgrid link: Reason for failure: Anything else we need to know: /sig scheduling /assign
I just sent a pr for it according to the error message, but I'm not very sure if it will make things all right.
/assign
Change:
.PHONY: generated_files generated_files: gen_deepcopy gen_defaulter gen_conversion gen_openapi <ins> .PHONY: verify_generated_files verify_generated_files: verify_gen_deepcopy     verify_gen_defaulter    verify_gen_conversion   verify_gen_openapi </ins> # Code-generation logic. # # This stuff can be pretty tricky, and there's probably some corner cases that

Discussion:
Right now on head () if you run it will end up having a modified file. This happened because some type has been changed and this file should have been generated before commit, and verification should have failed but they didn't.
This is not only a problem with openapi-gen. deepcopy-gen also has the same problem. I've a field to a type (autoscaling/v1) and verify-all passed for the commit (without adding generated code to it). those files will be generated on verify-codegen and it will not fail and the commit can be merged without generated code.
Yeah. So when the Makefile stuff originally went in those files were not checked in. Then we un-did that part, but I didn't re-add them to verify...
Change:
"k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/wait" <ins> watch "k8s.io/apimachinery/pkg/watch" </ins> clientset "k8s.io/client-go/kubernetes" <ins> watchtools "k8s.io/client-go/tools/watch" </ins> cloudprovider "k8s.io/cloud-provider" "k8s.io/kubernetes/test/e2e/framework" e2edeployment "k8s.io/kubernetes/test/e2e/framework/deployment"

Discussion:
[x] Original approval issue: [x] Two weeks soak end date: This issue is created to allow edit by /wip /hold This issue proposes the writing of a new test for the API endponts , , , with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to this APIsnoop query, there are still some remaining Endpoints endpoints which are untested. a Service in a namespace all Endpoints in all Namespaces find the created Service(1) /update the Namespaced Endpoint for the Service(1) the Namespaced Endpoint for the Service(1) the Namespaced Endpoint for the Service(1) Namespaced Endpoint(1) via a Collection with a LabelSelector Discover useragents: If a test with these calls gets merged, Conformance coverage will go up by 4 points* /sig testing /sig architecture /area conformance
/reopen Wait for Promotion PR to Merge.
Reopened this issue. <detailsIn response to : /reopen Wait for Promotion PR to Merge. 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:
"ip_vs_wrr", "ip_vs_sh", "nf_conntrack_ipv4", <ins> "nf_conntrack", </ins> } // In IPVS proxy mode, the following flags need to be set

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!--kube-proxy cannot use ipvs mode on Linux 4.19 due to a check for the module, which was changed to (). uses to check for : It should instead accept on Linux 4.19 or above. What happened: kube-proxy fell back from ipvs mode to iptables mode. What you expected to happen: kube-proxy using ipvs. How to reproduce it (as minimally and precisely as possible): Launch a cluster on an image using Linux 4.19 or above with kube-proxy using ipvs mode (see ). Environment: Kubernetes version (use ): All Kernel (e.g. ): 4.19 <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig network
/area ipvs /assign /cc
Okay, so should check {nfconntrackipv4 | nf_conntrack} and expect load at least one module?
I think so
Please just go ahead :)