jiebi/CodeConvo huggingface dataset:
Change:
package serviceaccount import ( <del> "bytes" </del> "context" <ins> "crypto/subtle" </ins> "encoding/json" "errors" "fmt"

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:
type KubeletConfig struct { EtcdClient              tools.EtcdClient DockerClient            dockertools.DockerInterface <ins> CAdvisorPort            uint </ins> Address                 util.IP AuthPath                string ApiServerList           util.StringList

Discussion:
Currently, kubelet uses a for communicating with cAdvisor. , were having an issue because we didn't realize making port available was required for kubernetes.
I prefer not do this since we plan to make 4194 publically reserved port for cAdvisor. Also cAdvisor is the default deamon running on every node of a kubernetes cluster. The issue you encountered sounds like a bad document issue we had for cAdvisor. We should fix the document instead of allow the port being configurable.
can you expound on 'bad document' issue?
Change:
embed = [":go_default_library"], deps = [ "//pkg/apis/core:go_default_library", <ins> "//pkg/controller/volume/persistentvolume/util:go_default_library", </ins> "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library",

Discussion:
API server latency for PV creation depends on underlying cloud API latency. We have admission plugin that examines incoming PV and adds topology labels and node selector: When the cluster (and cloud) are under pressure, e.g. lot of PVCs are created and dynamically provisioned at one time and attached to nodes, API server latency increases. We've seen cases when we ran out of cloud API request quota and the admission plugin needed to sleep for couple of seconds (on AWS). There should be an easy fix: check, if the created PV already has all necessary labels and topology information and ask the cloud for them only when they're missing. Dynamically provisioned volumes already have these labels. The admission plugin will then ask the cloud only for manually provisioned PVs, which we believe is just a fraction of all PVs in the cluster. There is one glitch: previously, when user created a PV with wrong topology labels, the admission plugin corrected them. With the fix suggested above, this PV won't be corrected. /sig storage cc
Implementation of the above:
Change:
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object // +genclient:method=GetScale,verb=get,subresource=scale,result=k8s.io/api/autoscaling/v1.Scale // +genclient:method=UpdateScale,verb=update,subresource=scale,input=k8s.io/api/autoscaling/v1.Scale,result=k8s.io/api/autoscaling/v1.Scale <ins> // +genclient:method=CreateScale,verb=create,subresource=scale,input=k8s.io/api/autoscaling/v1.Scale,result=k8s.io/api/autoscaling/v1.Scale </ins> type ClusterTestType struct { metav1.TypeMeta `json:",inline"`

Discussion:
What happened: Test create method for non-namespaced subresources generate invalid code. I have the following code generation annotations: which generated test method with generated fake client: What you expected to happen: It should be: How to reproduce it (as minimally and precisely as possible): Generate clients for non-namespaced resources with subresources (like scale) like this: /sig api-machinery /area code-generator /assign
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: What you expected to happen: It should be: How to reproduce it (as minimally and precisely as possible): Generate clients for non-namespaced resources with subresources (like scale) like this: /sig api-machinery /area code-generator /assign 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
/assign
/triage accepted
Change:
var _ = utils.SIGDescribe("Volume expand", func() { var ( <del> c           clientset.Interface ns          string err         error pvc         *v1.PersistentVolumeClaim resizableSc *storage.StorageClass </del> <ins> c               clientset.Interface ns              string err             error pvc             *v1.PersistentVolumeClaim storageClassVar *storage.StorageClass </ins> ) f := framework.NewDefaultFramework("volume-expand")

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: I created a block EBS volume using dynamic provisioning. Then I resized the volume from 10GB to 20 GB. Both PV and block volume reflects the change, but the PVC's capacity is still 10GB. This could be caused by in-tree resize put the PVC condition under state, but no one is acting on the condition since it is block volume: /cc /sig storage What you expected to happen: PVC's capacity should be updated to 20GB How to reproduce it (as minimally and precisely as possible): Easy to reproduce using following specs: StorageClass: Claim: Pod: Anything else we need to know?: This will affect whether CSI migration should handle migration scenario for block volume resizing. Environment: Kubernetes version (use ):1.13 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: kops Network plugin and version (if this is a network-related bug): Others:
/sig aws
/assign
Change:
node: nodes[0], fits: false, test: "satisfies the PodAffinity but doesn't satisfies the PodAntiAffinity with the existing pod", <del> },*/ </del> <ins> }, </ins> { pod: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{

Discussion:
A significant number of the of are commented out, possibly was done by mistake in the past. I uncommented the tests to see if they pass, but one of them failed. What we need is to uncomment those tests, fix the one that is not passing and remove the redundant ones if there are any. /sig scheduling /help
/assign I will be moving some of the tests to unit tests and leave a cleaner set of integration tests.
/remove-help
would you like to take this? I can provide guidance.
/help /unassign
/assign
/remove-help
Change:
nc.deletePods(node.Name) } } <ins> // Report node events. if readyCondition.Status == api.ConditionTrue && lastReadyCondition.Status != api.ConditionTrue { nc.recordNodeEvent(node, "ready") } if readyCondition.Status == api.ConditionFalse && lastReadyCondition.Status != api.ConditionFalse { nc.recordNodeEvent(node, "not_ready") } if readyCondition.Status == api.ConditionUnknown && lastReadyCondition.Status != api.ConditionUnknown { nc.recordNodeEvent(node, "unknown") } </ins> } } return nil

Discussion:
/cc
Is this from head? I've never seen this before, maybe changed anything recently. Anyway, the code in question will be deleted by
I saw this in the Travis run for an unrelated PR (Kubelet test refactoring). If it's going away, then that's ho we'll fix it :)
Yup. It'll go away. I'll assign it to myself - I'll run test few times after to make sure it's gone.
another example: https://travis-
Just hit this again: https://travis-
I was hoping we could finish getting rid of this code this week, which is why I had been ignoring this. But we ran out of time and Poland has a holiday on Monday, so I guess we need to fix this race. I'll take a look.
Thanks. This is becoming a real nuisance that is masking other failures.
To repro I assume I just type the commands from Travis, e.g. the shell stuff in https://travis- ?
Never mind, I got it. Though the first time I ran it all the tests passed.
I don't think the failure is deterministic, but yes.
This is super annoying, it happens way too much of the time...
Sigh, I was hoping we can get rid of the code this week. I think the problem comes from someone changes the event recording. I'll send a PR
It seems to be basically always failing now, except when some other flake fails first.
It would be fine with me if we just temporarily disabled event generation there.
If I'm reading the stack traces correctly, what's going on is that NewNodeController [] calls StartRecordingToSink() [] which calls StartEventWatcher() which calls eventHandler() which calls StartRecordingToSink() which calls sink.Create() which is Create() in , which appends to c.Fake.Actions. At the same time, the last line of the test tries to print "item.fakeNodeHandler.Actions" and these are presumably the same variable. I'm not sure why these are running at the same time, though.
+1 to Braians idea to temporary disable event generation.
Re-titled issue.
Re-titled issue.
Change:
return nil } <del> func collectAndCompare(t *testing.T, wantExtensionPoint string, wantStatus Code) { ch := make(chan prometheus.Metric, 1) m := &dto.Metric{} metrics.FrameworkExtensionPointDuration.Collect(ch) got := <-ch got.Write(m) </del> <ins> func collectAndCompareFrameworkMetrics(t *testing.T, wantExtensionPoint string, wantStatus Code) { m := collectHistogramMetric(metrics.FrameworkExtensionPointDuration) </ins> if len(m.Label) != 2 { t.Fatalf("Unexpected number of label pairs, got: %v, want: 2", len(m.Label))

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : metric name Description -- -- permitwaitduration_seconds Duration of permit extension point finishes waiting. Why is this needed: In permit extension point, if the status is "Wait", we block until the pod is scheduled or timeout: Blocking is an important behavior that we should monitor. /sig scheduling
/assign
Change:
} func createTooManyRequestsError(name string) error { <del> // TODO(mml): Add a Retry-After header.  Once there are time-based </del> <ins> // TODO: Once there are time-based </ins> // budgets, we can sometimes compute a sensible suggested value.  But <del> // even without that, we can give a suggestion (10 minutes?) that </del> <ins> // even without that, we can give a suggestion (even if small) that </ins> // prevents well-behaved clients from hammering us. <del> err := errors.NewTooManyRequests("Cannot evict pod as it would violate the pod's disruption budget.", 0) </del> <ins> err := errors.NewTooManyRequests("Cannot evict pod as it would violate the pod's disruption budget.", 10) </ins> err.ErrStatus.Details.Causes = append(err.ErrStatus.Details.Causes, metav1.StatusCause{Type: "DisruptionBudget", Message: fmt.Sprintf("The disruption budget %s is still being processed by the server.", name)}) return err }

Discussion:
This is a FEATURE REQUEST. AFAIK, eviciton is first used in in . If a eviction is not allowed, the caller will get a , without a RetryAfter advice. See, It looks like this: { "metadata": {}, "status": "Failure", "message": "Cannot evict pod as it would violate the pod's disruption budget.", "code": 429 } It will be very helpful for and others to have a non-empty field. cc:
/sig apps
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 /lifecycle frozen
/sig api-machinery
Change:
func podFitsResourcesInternal(pod *api.Pod, nodeName string, nodeInfo *schedulercache.NodeInfo, info *api.Node) (bool, error) { allocatable := info.Status.Allocatable allowedPodNumber := allocatable.Pods().Value() <ins> if int64(len(nodeInfo.Pods()))+1 > allowedPodNumber { return false, newInsufficientResourceError(podCountResourceName, 1, int64(len(nodeInfo.Pods())), allowedPodNumber) } </ins> podRequest := getResourceRequest(pod) if podRequest.milliCPU == 0 && podRequest.memory == 0 { return true, nil

Discussion:
Was there some reason only the checking to the scheduler, not Kubelet?
IIRC it was written at the time when we stated adding checking in Kubelet. In other words - no reason.
Change:
// - volumes bound to another claim // - volumes whose labels don't match the claim's selector, if specified // - volumes in Class that is not requested <ins> // - volumes whose NodeAffinity does not match the node </ins> if volume.Spec.ClaimRef != nil { continue } else if selector != nil && !selector.Matches(labels.Set(volume.Labels)) {

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?: /assign What happened: Volume got bound to PV on node "kubernetes-minion-group-82c8" When the pod went back through scheduling, the predicate returned success for other nodes even though we should have updated the PV cache to point to the PVC: I think in , instead of continuing if the node affinity doesn't match, it should fail if the PV is prebound.
This causes two issues: On the second pass, the scheduler may choose a different node. Then in Assume/Bind volumes, we'll also prebind a second set of PVs. If the scheduler chose a different node on the second pass, and the PVCs became fully bound in between the predicates and assume volumes, then assume volumes will return success and the pod will get scheduled to the wrong node.
Change:
// NodeMapper contains information to generate nameToNodeInfo and vcToZoneDatastore maps type NodeMapper struct { <ins> nodeInfoRWLock        *sync.RWMutex nameToNodeInfo        map[string]*NodeInfo vcToZoneDatastoresMap map[string](map[string][]string) </ins> } // NodeInfo contains information about vcenter nodes

Discussion:
Command run: vSphere intree volume test suite occasionally failed with the following error: The test suite should always pass. We may have a chance to hit this by running ` No response binary version: 1.27.4 </details<detailsvsphere </details<details</details<details</details<details</details<details</details
/assign
/sig testing storage ?
/triage accepted
Change:
return csiDriverName, nil } } <del> return "", fmt.Errorf("could not find CSI Driver name for plugin %v", pluginName) </del> <ins> return "", fmt.Errorf("could not find CSI Driver name for plugin %s", pluginName) </ins> } // GetInTreeNameFromCSIName returns the name of the in-tree plugin superseded by

Discussion:
I noticed that kube-controller-manager is consuming visible amount of CPU in completely idle 5k node cluster (~7 cores/s) while for comparison kube-apiserver was using much less that time. I fetched pprof and noticed that we are burning significant in metrics.(attachDetachStateCollector).CollectWithStability:! Going further, most of the cpu is used for fmt.Errorf for formatting v1.Volume in line 160: which is never actually used by the caller We do not use significant cpu for preparing error messages that are then ignored. pprof cluster with some pods and volumes. No response_ <details26.1 </details<detailsgke, any? </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
A trivial fix would be actually to change GetInTreePluginNameFromSpec to write only PV/Volume names instead of entire specs in error message.
/assign In scheduler we use this function to check if we can translate the in-tree PV to CSI, I think we also only need the name of the pv. I'll create a pr for this one line change.
/sig storage Instrumentation ?
Change:
var _ = Describe("Initial Resources", func() { f := NewFramework("initial-resources") <del> It("[Skipped] should set initial resources based on historical data", func() { </del> <ins> It("[Skipped][Autoscaling Suite] should set initial resources based on historical data", func() { // Cleanup data in InfluxDB that left from previous tests. influxdbClient, err := getInfluxdbClient(f.Client) expectNoError(err, "failed to create influxdb client") _, err = influxdbClient.Query("drop series autoscaling.cpu.usage.2m", influxdb.Second) expectNoError(err) _, err = influxdbClient.Query("drop series autoscaling.memory.usage.2m", influxdb.Second) expectNoError(err) </ins> cpu := 100 mem := 200 for i := 0; i < 10; i++ {

Discussion:
Jenkins project: kubernetes-e2e-gce-autoscaling failed last couple of runs: Initial Resources [Skipped][Autoscaling Suite] should set initial resources based on historical data Expected <int64: to be ~ <int:
couple failing instances:
Re-opening. This flaked again:
status?
The test is disabled and there is no plan to enable it within next few weeks, so closing the issue and I'll back to it some time in the future.
Change:
v1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/sets" <ins> "k8s.io/apimachinery/pkg/version" </ins> clientset "k8s.io/client-go/kubernetes" restclient "k8s.io/client-go/rest" )

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: N/A Which test(s) are failing: [] [sig-node] PreStop should call prestop when killing a pod [Conformance] Since when has it been failing: N/A Testgrid link: N/A Reason for failure: When spawning a Pod, it's container might start before all its networking plumbing has been completed. Thus, if the container tests / needs its network connectivity, it mgiht fail. The ` image tries to connect to the Kubernetes API, but if it cannot, the Pod will end up in an Error state. Retrying the Kubernetes API connection will avoid this issue. Anything else we need to know:
/sig node
/remove-sig node /sig testing
Change:
# Dry-run create the CR kubectl "${kube_flags[@]:?}" apply --server-side --dry-run=server -f hack/testdata/CRD/resource.yaml "${kube_flags[@]:?}" # Make sure that the CR doesn't exist <del> ! kubectl "${kube_flags[@]:?}" get resource/myobj || exit 1 </del> <ins> ! kubectl "${kube_flags[@]:?}" get resource/myobj 2>/dev/null || exit 1 </ins> # clean-up kubectl "${kube_flags[@]:?}" delete customresourcedefinition resources.mygroup.example.com

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: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: /sig cli /cc /milestone v1.20 /prority important-soon
after creating the CRD, before applying the CR, kubectl should wait until includes :
/assign
/assign is this issue related to ?
no, this is simply kubectl trying to apply a CR before the server has made the API available at all
Got it! and I have filed to address this issue.
Still happening:
still happening: looks like the root cause is not related to CRD: I think the message Error from server (NotFound): "myobj" not found is expected, as the CR was not actually created: /reopen
Reopened this issue. <detailsIn response to : still happening: I think the message Error from server (NotFound): "myobj" not found is expected, as the CR was not actually created: 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
yes, the actual error is later: Line 177 succeeds, and the next line fails:
Change:
} badName := "!@#$%^" badValue := "spaces not allowed" <ins> badAPIGroup := "example.com/v1" goodAPIGroup := "example.com" </ins> scenarios := map[string]struct { class        *resource.ResourceClass

Discussion:
Following YAML file is accepted without error. Notice the field, it is an instead of , containing character. This can lead to an issue when resource driver generates structured parameters' in-tree object with being just without version. The DRA scheduler plugin will try to match the parameters object based on the reference here: In latest master the code appears to use an indexer, and the issue might be hidden, if applicable at all. I did not check the reproducibility in master yet. However, main question is whether the should allow value with character in general. An error is expected from the apiserver upon object creation request, reporting that APIGroup containes APIVersion. Maybe. Have any resource driver that supports structured parameters, , for instance, also puts (gpucrd.APIGroup) value into . v1.30.1 <details</details<details</details<details</details<details</details<detailsscheduler's dynamicresources plugin </details
/sig node /triage accepted
/assign