jiebi/CodeConvo huggingface dataset:
Change:
func (csiNodeStrategy) ValidateUpdate(ctx context.Context, obj, old runtime.Object) field.ErrorList { newCSINodeObj := obj.(*storage.CSINode) oldCSINodeObj := old.(*storage.CSINode) <del> // in 1.22 on update, set AllowLongNodeID to true only if the old object already has a long node ID // in 1.23 on update, set AllowLongNodeID=true allowLongNodeID := false for _, nodeDriver := range oldCSINodeObj.Spec.Drivers { if validation.CSINodeLongerID(nodeDriver.NodeID) { allowLongNodeID = true } } </del> validateOptions := validation.CSINodeValidationOptions{ <del> AllowLongNodeID: allowLongNodeID, </del> <ins> AllowLongNodeID: true, </ins> } errorList := validation.ValidateCSINode(newCSINodeObj, validateOptions)

Discussion:
will be used as a preparation for relaxing CSI Node id length limitation, in 1.22, we need to make sure the AllowLongNodeID is set correctly according to the comment /sig storage /assign /cc
/milestone 1.22
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone 1.22 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
Can you make a better title - I almost jumped out of my skin :)
Oops, sorry about that lol
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Change:
return proxyModeUserspace } <ins> func detectNumCPU() int { return goruntime.NumCPU() } </ins> func tryWinKernelSpaceProxy(kcompat winkernel.KernelCompatTester) string { // Check for Windows Kernel Version if we can support Kernel Space proxy // Check for Windows Version

Discussion:
A new flag indicating how kube-proxy gets the number of CPUs, either from goruntime or . In kube-proxy, we can use to set node's , the resulting is . We have nodes where pods with none CPU policy and static CPU policy are running together. Pods like kube-proxy are running in none CPU policy by default, and they only gets CPUs left by static CPU policy pods. If static CPU policy pods take away most CPUs cores, kube-proxy can only get one or two cores, then will be set to a very small values. In this case, a lot packet failure can occur. When we set kube-proxy to work in static CPU policy, kube-proxy only gets the number of CPUs selected by the CPU policy, not the number of total CPUs on the node. This may surprise users who are only trying to limit kube-proxy's CPU usages, but resulting in some conntrack fulls faults. Please let me know if this enhancement is reasonable, so I can send a pr later. Thanks!
/sig network
Is it refer to deploy order of kube-proxy? If kube-proxy deploy first in node, will it get just one or two core?
By one or two I mean kube-proxy gets a small number of CPU cores, because most of CPU cores are allocated to static policy pods, sorry for the misunderstanding. The number of conntrack-max depends on the CPU cores when kube-proxy started, even kube-proxy was first deployed, it can get restarted or redeployed by some reasons. Then the conntrack-max will change.
yeah, when kube-proxy deploy firstly, Maybe it can see the whole cpu nums from shared cpu(/var/lib/kubelet/cpumanagestate when kubelet start with static cpu policy). But I think it is a bug for kube-proxy. The cpu info can also get from node resource info. So will it be suitable to add a flag to set cpu num?
Maybe, or we can add a flag for user to choose where kube-proxy should get CPU informations from. There maybe some multi-tenant scenarios where kube-proxy are deployed for per tenant so they would like to limit conntrack-max by CPU cores allocated to each tenant.
I think the simple fix is to replace with something that counts /proc/cpuinfo. I don't know of anyone running multiple proxies, and I don't think it would work well. The intention was "all the CPUs on the node". PRs welcome!
/triage accepted
Change:
test/e2e/network/service.go: "should be able to change the type from ExternalName to NodePort" test/e2e/network/service.go: "should be able to change the type from ClusterIP to ExternalName" test/e2e/network/service.go: "should be able to change the type from NodePort to ExternalName" <ins> test/e2e/network/service.go: "should find a service from listing all namespaces" </ins> test/e2e/network/service_latency.go: "should not be very high" test/e2e/node/events.go: "should be sent by kubelets and the scheduler about pods scheduling and running" test/e2e/node/pods.go: "should be set on Pods with matching resource requests and limits for memory and cpu"

Discussion:
This issue proposes the writing of a new test for the API endpoint 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. There are no tests listing services, see the following: This mock test uses client-go's functions and hits the endpoints. This shows the endpoints hit by my approach: /sig architecture /area conformance
Change:
github.com/coreos/go-oidc v2.2.1+incompatible github.com/coreos/go-systemd/v22 v22.5.0 github.com/cpuguy83/go-md2man/v2 v2.0.2 <del> github.com/cyphar/filepath-securejoin v0.2.3 </del> <ins> github.com/cyphar/filepath-securejoin v0.2.4 </ins> github.com/distribution/reference v0.5.0 github.com/docker/go-units v0.5.0 github.com/emicklei/go-restful/v3 v3.9.0

Discussion:
One of the dependencies of k8s, filepath-securejoin, has a following vulnerability discovered: It has been patched in version 0.2.4, however k8s is still using version 0.2.3. Potential fix: updating the dependency. A small PR will follow. /sig security
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 security
/kind bug /sig security
Change:
}, "topologyKey": { "type": "string", <del> "description": "This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. For PreferredDuringScheduling pod anti-affinity, empty topologyKey is interpreted as "all topologies" ("all topologies" here means all the topologyKeys indicated by scheduler command-line argument --failure-domains); for affinity and for RequiredDuringScheduling pod anti-affinity, empty topologyKey is not allowed." </del> <ins> "description": "This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed." </ins> } } },

Discussion:
The field is marked as optional: The comment also describes a use case for empty topologykey: But the validation rule says it's required:
cc
cc could you take a look? Thank you. The validation rule is by
the release note of should go into the "action-required" section of the , but it's currently in "Other notable changes".
/assign
It seems that we should also update the external api type comments. Right?
I will look into it today.
If you didn't work on this, I am pleasure to send PR to fix this. :)
yeah sure. thanks.
Change:
grabFromScheduler                 bool grabFromClusterAutoscaler         bool kubeScheduler                     string <ins> waitForSchedulerReadyOnce         sync.Once </ins> kubeControllerManager             string waitForControllerManagerReadyOnce sync.Once }

Discussion:
! /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig instrumentation /assign
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
The flake happened in before.
This is fixed. !
/reopen This is still failing. Sample run:
Reopened this issue. <detailsIn response to : /reopen Sample run: 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
/priority critical-urgent
The error message in makes me think the apiserver is not available during that test run: . Can someone link to the frequency graphs to see if the problem is widespread?
got it:
I don't think I was right above. I think the "the server is currently unable to handle the request" is an error coming from the proxy. The proxy was around the time this issue was filed (), so it seems likely to be related to it. can you take a look?
This is a known issue, and is working on it . Now that is being blocked by the debugging handler problem, could we merge to mitigate this problem first? cc
I would prefer to reach a decision about enabling the debug handlers, but if that's not possible, then merging PR as mitigation might make sense.
Think I hit this also.
It appears to still be failing based on
Why rebase? Any new test run will be based on merge with current k/k master and thus contain
<img width="1111" alt="Screen Shot 2021-05-28 at 13 04 52" src="https://user-" looks like it has become more stable now.
/close
Closing this issue. <detailsIn response to : /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:
import ( "encoding/json" "fmt" <del> "runtime" </del> <ins> "math/rand" </ins> "strconv" "testing" "time"

Discussion:
Have not reproduced locally even after a few tens of runs.
which version of Go are you using locally? This probably only repros on 1.5.1.
This was from Jenkins runs.
This is caused because an attempts counter is being read/written to without synchronization. I think this is caused by the event creation order not being guaranteed. I am looking a little deeper to track this down.
Got a fix with 130k+ runs and no failures. Will send out PR shortly.
Change:
} // errEmptyName is returned when API requests do not fill the name section of the path. <del> var errEmptyName = fmt.Errorf("name must be provided") </del> <ins> var errEmptyName = errors.NewBadRequest("name must be provided") </ins> // Installs handlers for API resources. func (a *APIInstaller) Install() (ws *restful.WebService, errors []error) {

Discussion:
e.g. REST.Update should never return an arbitrary error value. Maybe we should change the return code to something stricter than generic error.
/cc
FYI: is for remaining cases where the API doesn't return JSON/Status errors.
Re-opening this until we
I think etcd errors require more abstraction, also:
There are some admission control plugins that did not always follow that practice which I will resolve as part of
Are there any known instances of this remaining?
None that I know of.
Change:
epSlice1NewerGen := epSlice1.DeepCopy() epSlice1NewerGen.Generation = 2 <ins> epTerminatingSlice := epSlice1.DeepCopy() now := metav1.Now() epTerminatingSlice.DeletionTimestamp = &now </ins> testCases := []struct { name         string tracker      *EndpointSliceTracker

Discussion:
As discussed in , Endpoint(Slice) controllers can get stuck if an Endpoints or EndpointSlice resource is stuck in a terminating state. I don't think there's much we can do for Endpoints here since the same name is reused, but EndpointSlice controllers can ignore EndpointSlices in a terminating state. See No response All supported versions Any Any Any Any Any
/sig network
/triage accepted
deleting a service with a finalizer doesn't affect the endpointslice, it doesn't change its status to termination or unready Repro: finalizer to the service and delete it, it keeps waiting until the finalizer is removed with the deletion timestamp set. the endpoint slice associated Do you mean that when the endpoint slice controller detects that the Service is being deleted should switch the endpoint slice status to Terminating? cc:
I don't think we need to do anything special if the Service is waiting to be deleted. There are many legitimate reasons for this to happen, including waiting for infrastructure to be removed. My main concern with a finalizer was that one on an EndpointSlice could cause the controller to get stuck on a Service. We don't have the same risk with a finalizer on a Service - I don't think that would cause the controller to get stuck in any way.
i was unable to repro the issue on my machine: I was monitoring the logs of , and the endpointslice controller never complained about , when I deleted the service. Though, I was able to get the controller to log this error under a different scenario. If we don't explicitly remove the finalizer from the endpointslice, and instead re-create the pod and service like: From what I can understand, because the endpointslice with the finalizer is owned by a service with a different UID than the new endpointslice, it is marked as expected for deletion . The endpointslice controllers calls , which returns true for the endpointslice with the finalizer, because of the above reason. I might be wrong anywhere here, so please let me know if that is the case. As for further action, I'm not sure what can be done here? We could check the endpointslice for finalizers and then skip them . Keen to hear your thoughts about this.
Change:
return fmt.Errorf("failed to create fsnotify watcher: %v", err) } defer watcher.Close() <del> if err := watcher.Add(f.Name()); err != nil { return fmt.Errorf("failed to watch file %q: %v", f.Name(), err) </del> <ins> if err := watcher.Add(dir); err != nil { return fmt.Errorf("failed to watch directory %q: %w", dir, err) </ins> } // If we just created the watcher, try again to read as we might have missed // the event.

Discussion:
won't output logs after kubelet rotate log filer of the container. kubectl output logs correctly after the log file is rotated. the config to . So kubelet will rotate the log soon. Build a image with this program a deploy with the previous image. the command No response <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig node
/area kubelet
/triage accepted /priority important-longterm
/assign since you sent a PR already
Ran into this issue!
Change:
} nodeV, _ := nodeConstraints[k] if v != nodeV { <del> glog.V(2).Infof("Won't schedule pod %q onto node %q due to volume %q (mismatch on %q)", pod.Name, node.Name, pvName, k) </del> <ins> glog.V(10).Infof("Won't schedule pod %q onto node %q due to volume %q (mismatch on %q)", pod.Name, node.Name, pvName, k) </ins> return false, []algorithm.PredicateFailureReason{ErrVolumeZoneConflict}, nil } }

Discussion:
Problem There are at least some examples of over logging in the scheduler. Solution Go through glog.Info and make sure we are consistently managing logs. At least one example to solve in an easy PR has shared with us.. Ill confirm this is happening still in upstream kube and fix as well as audit the others.
part of
yeah lets de-dupe the tickets, we have 3+ issues on this now.. closing this one. just submit the PRs and reference one of the other tickets.
Change:
// Detach detaches a volume from the host.  This is only needed when NBD is not // enabled and loop devices are used to simulate a block device. func (u *storageosUtil) DetachVolume(b *storageosUnmounter, devicePath string) error { <ins> klog.V(4).Infof("detaching StorageOS volume %q with namespace %q", b.volName, b.volNamespace) </ins> if !isLoopDevice(devicePath) { return nil }

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: When a PVC is created and the PV mounted into a Pod using the StorageOS in-tree volume driver, the StorageOS CLI & UI do not report that the volume is mounted. The PV is created and mounted into the Pod successfully, and all k8s functionality works as expected. However, since the correct mount status is not visible to administrators using the StorageOS UI or CLI, they may make changes to or delete a mounted volume without realising, and the safeguards (must use to delete a mounted volume) do not trigger. This is a regression caused by , released in 1.14.0. What you expected to happen: The StorageOS CLI should report volume mount information (node name, mount timestamp). How to reproduce it (as minimally and precisely as possible): StorageOS node containers with CSI disabled: application Pod with a PVC using the StorageOS StorageClass: StorageOS to list volumes: Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.0 and later Cloud provider or hardware configuration: any OS (e.g: ): any linux (incl. Ubuntu 18.04) Kernel (e.g. ): any linux (incl. 4.15.0-33-generic) Install tools: any (incl. minikube) Network plugin and version (if this is a network-related bug): N/A Others: Requires StorageOS deployment /sig storage /assign
Change:
klog.V(4).Infof("Token is deleted and awaiting removal: %s/%s for service account %s/%s", namespace, secretName, namespace, serviceAccountName) return nil, errors.New("Token has been invalidated") } <del> if !bytes.Equal(secret.Data[v1.ServiceAccountTokenKey], []byte(tokenData)) { </del> <ins> if subtle.ConstantTimeCompare(secret.Data[v1.ServiceAccountTokenKey], []byte(tokenData)) == 0 { </ins> klog.V(4).Infof("Token contents no longer matches %s/%s for service account %s/%s", namespace, secretName, namespace, serviceAccountName) return nil, errors.New("Token does not match server's copy") }

Discussion:
This issue was reported in the Impact An attacker may be able to guess a service account token secret, and impersonate the affected account to read, modify, or delete application data to which the account has access in a Kubernetes cluster. Description Service account token secrets () are a type of secret used to authenticate service accounts. The “Service account token Secrets” section of the Kubernetes “Configuration” documentation does not recommend their usage: Nevertheless, their usage appears to be possible, and may be employed by Kubernetes users. The process of creating a service account token is documented in the “Configure Service Accounts for Pods” documentation section. An incoming service account request is authenticated by first verifying the JWT signature of the token, then by comparing the secret token value embedded in the request, against the server’s record of the value. If the values don’t match, the authentication request is rejected. The comparison is performed in a non constant-time way; that is, it will return as soon as it reaches mismatched bytes between the two values. This leaks information about the token, which may assist attackers in successfully guessing the secret value. The issue is present in function of file (). Recommendation Compare the token secret values in constant-time. This can be achieved by using Go’s of the subtle package. Component kube-apiserver Location Function in file Anything else we need to know? See umbrella issue for current status of all issues created from these findings. The vendor gave this issue an ID of NCC-E003660-PCK and it was finding 16 of the report under the kube-apiserver section. The vendor considers this issue Risk as Informational, High Impact, Exploitability at None To view the original finding, begin on page 45 of the Test Environment Kubernetes 1.24.3
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 security
/assign
/sig auth
Change:
fi # If there are no more remaining master replicas: delete routes, pd for influxdb and update kubeconfig <del> if [[ "${REMAINING_MASTER_COUNT}" == "0" ]]; then </del> <ins> if [[ "${REMAINING_MASTER_COUNT}" -eq 0 ]]; then </ins> # Delete routes. local -a routes # Clean up all routes w/ names like "<cluster-name>-<node-GUID>"

Discussion:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): upgrade test leak Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5 beta Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: kube- What happened: While doing manual upgrade testing, found that I couldn't start a new cluster as the existing firewall rules and external master ip address reservation where preventing kube-up from succeeding after running kube-down What you expected to happen: kube-down to clean up all cluster related resources How to reproduce it (as minimally and precisely as possible):
I tried this on a different GCP project and it didn't reproduce. I'm going to see if there's anything strange about my project.
Ack marking this as non-release-blocker
I think I found the problem. (from ) evaluates to false in bash on my mac. Changing it to fixes my issue. I'll send out a PR.
Change:
return nil } clone.Revision = newRevision <del> updated, updateErr := rh.client.Apps().ControllerRevisions(clone.Namespace).Update(clone) </del> <ins> updated, updateErr := rh.client.AppsV1beta1().ControllerRevisions(clone.Namespace).Update(clone) </ins> if updateErr == nil { return nil }

Discussion:
The statefulset controller and controller history implementations should be migrated off of the Apps client (deprecated) and onto the AppsV1BetaClient. Currently there is no user facing issue caused by the use of the deprecated resource, but we should maintain good code hygiene.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
/assign kow3ns
/assign kow3ns
/cc
/assign