jiebi/CodeConvo huggingface dataset:
Change:
expected: new(spec.Schema), }, { <ins> name: "nullable required", in: &apiextensions.JSONSchemaProps{ Type: "object", Properties: map[string]apiextensions.JSONSchemaProps{ "a": { Nullable: true, Type:     "string", }, "b": { Nullable: true, Type:     "string", }, "c": { Type: "string", }, }, Required: []string{"a", "c"}, }, expected: &spec.Schema{ SchemaProps: spec.SchemaProps{ Type: []string{"object"}, Properties: map[string]spec.Schema{ "a": {}, "b": {}, "c": { SchemaProps: spec.SchemaProps{ Type: []string{"string"}, }, }, }, Required: []string{"c"}, }, }, }, { name: "nullable required additionalProperties", in: &apiextensions.JSONSchemaProps{ Type: "object", AdditionalProperties: &apiextensions.JSONSchemaPropsOrBool{ Schema: &apiextensions.JSONSchemaProps{ Nullable: true, Type:     "string", }, }, Required: []string{"a", "c"}, }, expected: &spec.Schema{ SchemaProps: spec.SchemaProps{ Type: []string{"object"}, AdditionalProperties: &spec.SchemaOrBool{ Allows: true, Schema: &spec.Schema{}, }, }, }, }, { </ins> name: "title", in: &apiextensions.JSONSchemaProps{ Title: testStr,

Discussion:
When doing in an OpenShift cluster with a nullable field being required (compare ) and of value null, one gets:
cc
is there a way to also fix the faulty kubectl validation in 1.18.x?
Change:
unified := libcontainercgroups.IsCgroup2UnifiedMode() if unified { <del> libcontainerCgroupConfig.Path = m.buildCgroupUnifiedPath(cgroupConfig.Name) </del> <ins> libcontainerCgroupConfig.Path = cgroupConfig.Name.ToCgroupfs() </ins> } else { libcontainerCgroupConfig.Paths = m.buildCgroupPaths(cgroupConfig.Name) }

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: is created on a cgroup2 host What you expected to happen: Such directory should not be created How to reproduce it (as minimally and precisely as possible): Boot Ubuntu 20.04 with Install moby/moby with containerd/containerd and opencontainers/runc Install kubernetes-sigs/kind . This version uses as the base image. Run with Run Run to drop into the shell of the node The following directories are unexpectedly created. (No process seems to belong to these groups actually) Environment: (See above)
cc
/sig node
Change:
creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults <ins> name: system:certificates.k8s.io:certificatesigningrequests:nodeclient rules: - apiGroups: - certificates.k8s.io resources: - certificatesigningrequests/nodeclient verbs: - create - apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient rules: - apiGroups: - certificates.k8s.io resources: - certificatesigningrequests/selfnodeclient verbs: - create - apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults </ins> name: system:discovery rules: - nonResourceURLs:

Discussion:
/kind feature From: Would it make sense to add these rules to the bootstrappolicy? To me they seem generic enough, and they wouldn't bind to something. Consumers can do the binding to their subjects as they like. I'm asking because it's already duplicated twice for two early adopters: I don't think those ClusterRoles are specific to kubeadm and GKE at all; but the ClusterRoleBindings will surely be, so therefore we'd create the roles but not the bindings.
Wouldn't we expect and encourage people using the CSR capability for their nodes to use node identities that match the node authorizer, in which case we won't need the client or server renewal CSR roles?
The node authorizer doesn't grant these, since otherwise you could never prevent a compromised node from renewing its credentials
Realistically, with these roles you still wouldn't. People would grant them to the node group, not each individual node, but I guess that would be a tradeoff for the deployment mechanism.
You could individually revoke this role from the group and stop renewals without disrupting regular operation
I can definitely see myself revoking a binding from to multiple specific bindings in case of a compromise. Anyway, this issue is more "should we create these by default or not". I've already mentioned my opinion.
Creating the roles seems reasonable. I don't think I want bindings. I think the binding should be up the particular deployer.
Perfect, that's exactly my proposal. I'll go ahead and make this change...
/assign
are you working on this or should I send a PR?
Change:
github.com/ThalesIgnite/crypto11 v1.2.5/go.mod h1:ILDKtnCKiQ7zRoNxcp36Y1ZR8LBPmR2E23+wTQe/MlE= github.com/davecgh/go-spew v1.1.0 h1:ZDRjVQ15GmhC3fiQ8ni8+OwkZQO4DARzQgrnXU1Liz8= github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= <del> github.com/go-logr/logr v1.2.4 h1:g01GSCwiDw2xSZfjJ2/T9M+S6pFdcNtFYsp+Y43HYDQ= </del> github.com/gogo/protobuf v1.3.2 h1:Ov1cvc58UF3b5XjBnZv7+opcTcQFZebYjWzi34vdm4Q= github.com/gogo/protobuf v1.3.2/go.mod h1:P1XiOD3dCwIKUDQYPy72D8LYyHL2YPYrpS2s69NZV8Q= github.com/golang/protobuf v1.5.0/go.mod h1:FsONVRAS9T7sI+LIUmWTfcYkHO4aIWwzhcaSAoJOfIk=

Discussion:
Drop the and dependencies from to keep the import lighter. /sig auth /triage accepted
/assign Hi, , I created a PR to fix this. I am not sure If I am correct due to the repo seems generated. Would you like to provides some hints for me?
This will likely require a new go module in to move the client-go dep and then mark it as internal, ex: . is the only API machinery dep so we can probably come up with some way to re-implement the wait logic locally? Then we drop these lines so that these imports do not come back again:
Whoa, yeah, I'd take a for loop and a time.Sleep in a test to drop those deps
What is kms using client-go for? Tests only?
These were all needed by the KMS repo back when we had a much more complicated reference implementation which required a key hierarchy. Now they are just used in some tests and mock implementations, so we should be able to simplify things.
I found a place for rate limit. #liggitt
that package just delegates to "", switch that mock provider to use that directly?
Change:
health kubernetes __PILLAR__DNS__DOMAIN__ in-addr.arpa ip6.arpa { pods insecure <ins> upstream </ins> fallthrough in-addr.arpa ip6.arpa ttl 30 }

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-network] DNS configMap nameserver [IPv4] Forward external name lookup should forward externalname lookup to upstream nameserver [Slow][Serial] Since when has it been failing: Failing since 6/10 at 16:58. . Decent chance that the failure is due to Testgrid link: Reason for failure: /cc /priority critical-urgent /kind failing-test /milestone v1.15 /cc
This is blocking the release /cc
I noticed in the it thinks it's testing 1.16 alpha:
/assign
should fix it. Sorry for the mess-up!
Change:
"net/http" "net/http/httptest" "reflect" <ins> "strings" </ins> "testing" "github.com/GoogleCloudPlatform/kubernetes/pkg/api"

Discussion:
The apiserver proxy rewrites links to the form "/proxy/ns/default/...": But this form stopped working recently, seemingly around The "/proxy/ns/default/..." form always returns "404: Page Not Found", similar to the problem seen in If you remove "/ns/default" from the URL, it works.
/cc
I can investigate this as well.
I see the issue, sending a PR.
The proxy path needs to be built with knowledge of the apiversion of the incoming proxy request, and it needs to be updated to use the knowledge from the restmapper. This is a little trickier than I have time for right now, but it should definitely not be hardcode appending the /ns form. Not clear why this is not also caught by our test case. I can try and look at this more in the AM unless someone else wants to take a look in interim. /cc
Let me steal this one from you, I think I can fix it.
Have at it. /cc me on your PR
Sorry, I see you've already got a PR out!
No problem. I would be happy if you finished my PR relative to the commit I started. It will be a few days before I can go back to looking at this issue. I think v1beta1/v1beta2 proxy urls in go-restful need to always but the namespace scope in the path as the ultimate fix. I do want the proxy to have access to the restmapper per my PR. ----- Original Message ----- From: "Daniel Smith" To: "GoogleCloudPlatform/kubernetes" Cc: "Derek Carr" Sent: Friday, February 13, 2015 4:56:19 PM Subject: Re: [kubernetes] apiserver proxy stopped accepting namespaces () Sorry, I see you've already got a PR out! Reply to this email directly or view it on GitHub:
Any updates ?
This is breaking monitoring since it requires the proxy. Bumping up the priority to P0.
Sorry for dropping this. Working on a fix.
Change:
import ( "fmt" "path" <del> "time" </del> "github.com/onsi/ginkgo" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-node-kubelet-orphans Which test(s) are failing: [sig-storage] EmptyDir volumes [It] pod should support shared volumes between containers [Conformance] Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know:
please don't CC sig-testing on every test failure :( we own the infrastructure etc. the sig-storage owns these tests.
Change:
"A kubelet process is already running, don't know what to do" } Log-Output "Creating kubelet service" <del> & sc.exe create kubelet binPath= "${env:NODE_DIR}kubelet.exe ${kubelet_args}" start= demand </del> <ins> & sc.exe create kubelet binPath= "${env:NODE_DIR}kube-log-runner.exe -log-file=${env:LOGS_DIR}kubelet.log ${env:NODE_DIR}kubelet.exe ${kubelet_args}" start= demand </ins> & sc.exe failure kubelet reset= 0 actions= restart/10000 Log-Output "Starting kubelet service" & sc.exe start kubelet

Discussion:
/kind feature Hey, in K8s 1.23 we are planning to deprecate multiple klog flags. Deprecated flags: , , , , , , , , , , , One of the alpha milestones is requires us to remove usage of deprecated flags within K8s repo. Examples found for windows [ ] [ ] /sig windows /wg structured-logging
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 I've started looking into this. Part of the problem is that go-runner is not part of kubernetes-node-windows- I suspect that is where the scripts get and kube- from.
Change:
var ValidateServiceAccountName = NameIsDNSSubdomain // maskTrailingDash replaces the final character of a string with a subdomain safe <del> // value if is a dash. </del> <ins> // value if it is a dash and if the length of this string is greater than 1. Note that // this is used when a value could be appended to the string, see ValidateNameFunc // for more info. </ins> func maskTrailingDash(name string) string { <del> if strings.HasSuffix(name, "-") { </del> <ins> if len(name) > 1 && strings.HasSuffix(name, "-") { </ins> return name[:len(name)-2] + "a" } return name

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 --My controller had a bug where it was setting , and the client I was using () returned an internal server error when I tried to create it. In the API server logs, there was a panic at this line: apimachinery validation logic should handle this case gracefully, and the API server should return a helpful error to the client. Create a resource with the GenerateName field set to "-". This happened on Kind running locally & AKS, both v1.20.2 Kubernetes version (use ): v1.20.2 Cloud provider or hardware configuration: Kind/laptop, AKS OS (e.g: ): Darwin/LinuxKit (i.e. docker for macOS), AKS Install tools: Kind
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig apimachinery 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 api-machinery
/assign
/assign /triage accepted
Change:
configs[BusyBox] = Config{list.PromoterE2eRegistry, "busybox", "1.36.1-1"} configs[CudaVectorAdd] = Config{list.PromoterE2eRegistry, "cuda-vector-add", "1.0"} configs[CudaVectorAdd2] = Config{list.PromoterE2eRegistry, "cuda-vector-add", "2.3"} <del> configs[DistrolessIptables] = Config{list.BuildImageRegistry, "distroless-iptables", "v0.6.1"} </del> <ins> configs[DistrolessIptables] = Config{list.BuildImageRegistry, "distroless-iptables", "v0.5.6"} </ins> configs[Etcd] = Config{list.GcEtcdRegistry, "etcd", "3.5.15-0"} configs[Httpd] = Config{list.PromoterE2eRegistry, "httpd", "2.4.38-4"} configs[HttpdNew] = Config{list.PromoterE2eRegistry, "httpd", "2.4.39-4"}

Discussion:
sgtm, add an issue labeled as release-blocking and in the milestone to either promote to 1.23.0 or revert this to 1.22.x before our 1.31 release Originally posted by in Kubernetes is being built and tested with go1.23rc2 at HEAD () to let it bake in the CI and help iron out issues, if any, with this version of Go. However, for the 1.31 release, the version of Go should be a non-rc, released version. The release timeline of go1.23.0 is ~same as the release timeline of K8s 1.31.0 (see ). If go1.23.0 is not out by then, we should revert to go1.22.x before cutting K8s 1.31.0. /sig release architecture /area code-organization /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
/triage accepted /cc
/milestone v1.31
cc
xposting relevant slack thread:
Also unlike in the past, missing shipping 1.23.0 in 1.31.0 is not a big deal, we have much more room to switch to 1.23.0 in a patch release after all the compat changes with the go team. So we should not fear reverting if the timelines don't line up.
(though go1.23 adds the thing that makes it workable to default to old go version compat settings, so we'll have to eke out another 5 months on 1.21/1.22 for until we can adopt 1.23 on release branches in ~Jan if we miss 1.31, but that's how it looks like it will have to happen)
Change:
apiVersion: apps/v1beta1 kind: Deployment metadata: <del> name: event-exporter-v0.1.0 </del> <ins> name: event-exporter-v0.1.4 </ins> namespace: kube-system labels: k8s-app: event-exporter

Discussion:
Every time watch is reset, event exporter exports an entry about it to Stackdriver. To make it less irritating, this has to be done once per container run Related image PR: /cc
Change:
Ready            bool } <del> var _ = Describe("Container runtime Conformance Test", func() { </del> <ins> var _ = Describe("[FLAKY] Container runtime Conformance Test", func() { </ins> var cl *client.Client 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:
sandbox5        = makeFakePodSandbox("sandbox1-name", "sandbox5-uid", "sandbox1-ns", true) container7      = makeFakeContainer(sandbox5, cName7, 0, true) containerStats7 = makeFakeContainerStats(container7, imageFsMountpoint) <ins> // A pod that cadvisor returns no stats sandbox6        = makeFakePodSandbox("sandbox6-name", "sandbox6-uid", "sandbox6-ns", false) container9      = makeFakeContainer(sandbox6, cName9, 0, false) containerStats9 = makeFakeContainerStats(container9, imageFsMountpoint) </ins> ) var (

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: CPU.Time is set to cs.StartTime but ps.Memory.Time is set to timestamp when collecting the memoryusage. What you expected to happen: CPU.Time is set to cs.CPU.Time How to reproduce it (as minimally and precisely as possible): Check the code Anything else we need to know?: Environment: Kubernetes version (use ): master branch when creating this issue. 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:
/assign
/sig kubelet
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig kubelet 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 node
I am happy to take over this. /assign
Change:
resources.CpuPeriod = cpuPeriod } <ins> // runc requires cgroupv2 for unified mode if libcontainercgroups.IsCgroup2UnifiedMode() { resources.Unified = map[string]string{ // Ask the kernel to kill all processes in the container cgroup in case of OOM. // See memory.oom.group in https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html for // more info. "memory.oom.group": "1", } } </ins> return &resources }

Discussion:
Follow up on meeting of 28-03-2022 - In the meeting was specified that this most likely won't need a KEP and should be started with a Issue I see that the kernel in cgroups v2 has an option which would make all the pids of a given container to get killed on OOM: Some workloads that fork the process in the container, when the OOM kicks in, it kills only one process of the cgroup, causing a lot of noise due to process failures but health checks being successfull. We think that for our scenarios, killing all the pids in the containter would be better.
/cc
The way I’d summarize this issue with is: A small number of important workloads handle processes and OOM correctly (nginx, mature multi process systems like DBs) - we should not prevent these workloads from benefitting from per process OOM. A much larger and more diverse set of workloads are unlikely to handle OOM of multi process behavior incorrectly (bash child processes, especially in entrypoint scripts) - these users are unlikely to test OOM behavior in advance and thus are much more vulnerable to behaving incorrectly if we don’t default to killing the whole container. That also apples to containers with shared process namespaces. We generally bias towards the later group (low expertise / high diversity / low frequency / unlikely to read documentation) when designing our pod semantics, while allowing advanced users to set optional flags.
/cc
/cc
/sig node
/triage accepted /priority important-longterm
Change:
if !ok { return nil, false, nil } <del> if user.password != password { </del> <ins> if subtle.ConstantTimeCompare([]byte(user.password), []byte(password)) == 0 { </ins> return nil, false, nil } return &authenticator.Response{User: user.info}, true, nil

Discussion:
This issue was reported in the Description The kube-apiserver includes multiple authentication backends for client request processing. These range in strength from client certificate authentication to simple HTTP Basic Authentication. When using a password (Basic Authentication), the kube-apiserver does not perform a secure comparison of secret values. In theory, this could allow an attacker to perform a timing attack on the comparison. For example, the AuthenticatePassword function simply performs string comparison to authenticate a user’s password (Figure 9.1). Figure 9.1: Username and password authentication handling in Exploit Scenario Alice runs a Kubernetes cluster in production. In order to support multiple organizational “customers,” she configures the cluster with HTTP Basic Authentication. Eve has a large number of username and password pairs for the organization, and uses the side-channel information from string comparison to tune her credential-stuffing attacks. Recommendation Short term, use a safe, constant-time comparison function such as . The comparison function should take the same amount of time regardless of matching prefix data within the password. Long term, deprecate Basic Authentication in favor of more robust and secure options. Add documentation noting that any Basic Authentication is for use only in development scenarios, and not appropriate for production deployments. This will help users create a robust and secure default stance for all deployments. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of ATR-K8S-002 and it was finding 18 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 55 of the Environment: Kubernetes version: 1.13.4 Fixed in v1.16.0 by
/sig auth
/area security /kind bug /remove-kind feature