jiebi/CodeConvo huggingface dataset:
Change:
} func runPausePod(ctx context.Context, f *framework.Framework, conf pausePodConfig) *v1.Pod { <del> return runPausePodWithTimeout(ctx, f, conf, framework.PollShortTimeout) } func runPausePodWithTimeout(ctx context.Context, f *framework.Framework, conf pausePodConfig, timeout time.Duration) *v1.Pod { </del> pod := createPausePod(ctx, f, conf) <del> framework.ExpectNoError(e2epod.WaitTimeoutForPodRunningInNamespace(ctx, f.ClientSet, pod.Name, pod.Namespace, timeout)) </del> <ins> framework.ExpectNoError(e2epod.WaitTimeoutForPodRunningInNamespace(ctx, f.ClientSet, pod.Name, pod.Namespace, f.Timeouts.PodStartShort)) </ins> pod, err := f.ClientSet.CoreV1().Pods(pod.Namespace).Get(ctx, conf.Name, metav1.GetOptions{}) framework.ExpectNoError(err) return pod

Discussion:
master-blocking kind-ipv6-master-parallel RuntimeClass should run a Pod requesting a RuntimeClass with scheduling without taints AdmissionWebhook [Privileged:ClusterAdmin] should honor timeout [Conformance] 01-27-2023 16:08 PST https://k8s- { failed [FAILED] timed out while waiting for pod runtimeclass-3517/without-label to be running In [It] at: @ 01/28/23 22:33:45.607 } No response kind 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
It looks like that “Kubernetes e2e suite: . Would we want to reopen this issue? I will keep a close eye on to see if it continues to flake.
Reopen to monitor failures cc
/sig node /cc
/retitle [It] [sig-node] RuntimeClass should run a Pod requesting a RuntimeClass with scheduling without taint
Example failure:
Failure The pod was created at , from the kubelet logs: so the pod started at , but it was deleted at because the 1 minute timeout was hit. It looks like the container startup took a while based on containerd logs: there is a gap there of and between and
It is hitting this timeout - That uses which is 1 min which seems to be too short. We should probably use or which is 5min or 2min, because the whole pod needs to start and it seems like 1min is too short in this case.
Change:
for _, test := range testCases { host := "1.2.3.4" container := api.Container{ <del> Ports: []api.ContainerPort{{Name: "found", HostPort: 93}}, </del> <ins> Ports: []api.ContainerPort{{Name: "found", ContainerPort: 93}}, </ins> LivenessProbe: &api.Probe{ Handler: api.Handler{ TCPSocket: test.probe,

Discussion:
When using probe, define the port by number, it works. But if the port is defined by name like below, it doesn't work. it seems should return other than .
Change:
responses: 200: body: <del> application/json: example: !include examples/controller-list.json </del> <ins> example: !include examples/controller-list.json </ins> post: description: Create a new controller. currentState is ignored if present. body: <del> json/application: schema: !include doc/controller-schema.json example: !include examples/controller.json </del> <ins> schema: !include doc/controller-schema.json example: !include examples/controller.json </ins> /{controllerId}: get:

Discussion:
Starting a large data set (32gb allocated, 4gb resident) in the api server causes about 7.5gb allocations of . The tree for that shows: This appears to be due to openapi aggregation. If there is an easy fix in 1.7 it might be worth it. Otherwise this should be addressed for 1.8.
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
This is all API server startup - for small clusters it's about 20-60% of startup time
Most of those are that is the library we used to convert our spec to proto. The key is this line: Do you have any idea how we can get a better space time/complexity here?
I have a PR for that now.
Fixed in
Even without aggregation, starting and serving OpenAPI docs was a huge chunk of startup time. The linked change makes it disappear.
This should not be related to aggregation at all (as far as I can tell from that tree). Thanks for the fix
Thanks, it's in gnostic master now.
Change:
import ( "fmt" "path" <ins> "time" </ins> . "github.com/onsi/ginkgo" "k8s.io/api/core/v1"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : This is a place holder to track Conformance Coverage on the Topic. This issue should remain open until all related work is accomplished in the k/k repo This issue will contain analysis of the coverage. Existing tests and additional tests requested with links to those issues/PR's Why is this needed: Conformance coverage for CSI, etc. /area conformance /assign /cc
/sig testing
Change:
} if nc.runTaintManager { <ins> nc.taintManager = scheduler.NewNoExecuteTaintManager(kubeClient) </ins> nodeInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: util.CreateAddNodeHandler(func(node *v1.Node) error { nc.taintManager.NodeUpdated(nil, node)

Discussion:
Just saw this while running kube master locally: Yet to investigate more closely and check which PR could have introduced this. cc
/sig node
any way to repro?
I think I can fix this error.
what is the bug?
I think when call nc.taintManager has not been inited
duplicate of , fixed by
I found does not have related fix.
It fixes the issue systemically by not starting the informers until all controllers have finished setting up
Ok by more carefully read, I see.
fixed by
Change:
rm -fr pki mkdir -p pki openssl genrsa -out pki/ca.key 2048 <del> openssl req -new -x509 -days 3650 -key pki/ca.key -subj "/CN=pod-security-webhook-ca-$(date +%s)" -out pki/ca.crt </del> <ins> openssl req -sha256 -new -x509 -days 3650 -key pki/ca.key -subj "/CN=pod-security-webhook-ca-$(shell date +%s)" -out pki/ca.crt </ins> <del> openssl req -newkey rsa:2048 -nodes -keyout pki/tls.key -subj "/CN=webhook.pod-security-webhook.svc" -out pki/tls.csr </del> <ins> openssl req -sha256 -newkey rsa:2048 -nodes -keyout pki/tls.key -subj "/CN=webhook.pod-security-webhook.svc" -out pki/tls.csr </ins> echo "subjectAltName=DNS:webhook.pod-security-webhook.svc" > pki/extensions.txt echo "extendedKeyUsage=serverAuth" >> pki/extensions.txt <del> openssl x509 -req -extfile pki/extensions.txt -days 730 -in pki/tls.csr -CA pki/ca.crt -CAkey pki/ca.key -CAcreateserial -out pki/tls.crt </del> <ins> openssl x509 -sha256 -req -extfile pki/extensions.txt -days 730 -in pki/tls.csr -CA pki/ca.crt -CAkey pki/ca.key -CAcreateserial -out pki/tls.crt </ins> # Publishes the PodSecurity webhook Docker image to the configured registry. push:

Discussion:
The existing validating webhook PKI configurations fail on Kubernetes v1.24 due to Pod security webhook information example: Example API server error: Additionally: Date is not being interpolated in CA cert CN : "pod-security-webhook-ca-" CA Cert example information:
/transfer kubernetes /sig auth /kind bug
/help
This request has been marked as needing help from a contributor. 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 : /help 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
/triage accepted
Fixed in
Thank you
Change:
}) // This test verifies we don't allow scheduling of pods in a way that sum of <del> // limits of pods is greater than machines capacity. </del> <ins> // resource requests of pods is greater than machines capacity. </ins> // It assumes that cluster add-on pods stay stable and cannot be run in parallel // with any other test that touches Nodes or Pods. // It is so because we need to have precise control on what's running in the cluster.

Discussion:
What happened: I am questioning validity of the test. Comments under of say: The test scenario described as it is sounds reasonable. The only nitpick I have is the very first sentence saying "". Pod's resource limits are ignored in predicates. They take effect in the scoring phase when priorities are computed. Also, priorities are computed only when there are at least two candidate nodes. So after revisiting the step number 5 it's impossible to make sure the additional pod does or does not get scheduled when setting the resource limits. There are either no candidate nodes or one. In which case the limits are ignored and the test passes in the first case and fails in the second. In case there are at least two candidate nodes, one of them will always get picked. In which case the additional pod gets scheduled (no matter what the resource limits field says). In the framework: resource limits are accessed through method [1] is used to perform pre-scoring [2] in the scoring phase score is computed through method [3] The test is alternating between passing and failing state. It passes when predicates give empty list of candidate nodes and failing when the list of candidate nodes is non-empty. Thus, making the pod resource limits ineffective. [1] [2] [3] What you expected to happen: Have another node schedule the additional pod validating that all saturated nodes (with scheduled) have lower score (0 in case of plugin). Or, invalidate the test by removing it. Can anyone check the test validity and confirm/disprove my statement about ineffectiveness of the resource limits? How to reproduce it (as minimally and precisely as possible): Make sure there is at least one node with non-zero free cpu resource before running the step 5. Anything else we need to know?: Environment: Kubernetes version (use ): master HEAD Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
cc
I have noticed you refactored the test in Can you still recall the original intent of the test? I can't grasp how the limits are actually taken into account.
I agree, I think the test is wrong, the scheduler doesn't make fit decisions on resource limits. In the test, should have set. do you mind fixing the test and update the test comment please?
On it /assign
Change:
} type FakeEtcdClient struct { <ins> condWatchCompleted *sync.Cond condLock           sync.Mutex </ins> Data        map[string]EtcdResponseWithError DeletedKeys []string Err         error

Discussion:
Detected by
Create a Pod as follows: Name: jenkins Using image: jenkins In a new Kubenetes namespace named website-frontend kubectl create ns website-frontend apiVersion: v1 kind: Pod metadata: name: jenkins namespace: website-frontend spec: containers: name: jenkins image: jenkins kubectl create -f
Change:
defaultVersion, kind, err := api.RESTMapper.VersionAndKindForResource(a.GetResource()) if err != nil { <del> return admission.NewForbidden(a, err) </del> <ins> return errors.NewInternalError(err) </ins> } mapping, err := api.RESTMapper.RESTMapping(kind, defaultVersion) if err != nil { <del> return admission.NewForbidden(a, err) </del> <ins> return errors.NewInternalError(err) </ins> } if mapping.Scope.Name() != meta.RESTScopeNameNamespace { return nil

Discussion:
Currently the admission controller returns a forbidden (403) error if the namespace doesn't exist. We should return a 404 error instead.
Change:
"k8s.io/kubernetes/pkg/scheduler/profile" st "k8s.io/kubernetes/pkg/scheduler/testing" tf "k8s.io/kubernetes/pkg/scheduler/testing/framework" <del> testingclock "k8s.io/utils/clock/testing" "k8s.io/utils/ptr" </del> <ins> utiltesting "k8s.io/kubernetes/test/utils/ktesting" </ins> ) func TestSchedulerCreation(t *testing.T) {

Discussion:
/kind failing-test /kind flake First seen in an unrelated PR, but also occurs in periodic jobs. /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
/assign This feature is reverted once, and I fixed the flake, I'm cherry-pick that back again.
Change:
klog.Errorf("Failed to create govmomi client. err: %+v", err) return err } <ins> setVCenterInfoMetric(connection) </ins> return nil }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We need reporting of version to be shown in the metrics. Why is this needed: The goal behind this is to add some info about the underlying infrastructure for the kubernetes cluster. Some customers were experiencing issues during the cluster upgrades, but nothing in the upgrades themselves or kubernetes code for provider seemingly could cause those. The issue is storage related, and happening on a variety of releases with a significant delay from any other underlying infrastructure change, to which the kubernetes cluster has no relation and a way to know about. So knowing used hostnames, and versions associated with it over time would be extremely beneficial for debugging in similar circumstances. Some of the use cases we face: 1) A is enabled in a customer environment, and so there occurs a periodic automated vMotion for VMs backing kuberentes . We'd like to know on which host the actual kubernetes was located at any moment, and if any vCenter version transitions happened over time, new hosts /removed/renamed.
/sig cloud-provider /wg provider-vsphere
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cloud-provider /wg provider-vsphere 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
/area provider/vmware
Change:
expectDelete: false, }, { <del> description:  "terminated pod with emptyDir", node:         node, expected:     cordonedNode, pods:         []corev1.Pod{emptydirTerminatedPod}, rcs:          []corev1.ReplicationController{rc}, args:         []string{"node"}, expectFatal:  false, expectDelete: true, </del> <ins> description:           "terminated pod with emptyDir", node:                  node, expected:              cordonedNode, pods:                  []corev1.Pod{emptydirTerminatedPod}, rcs:                   []corev1.ReplicationController{rc}, args:                  []string{"node"}, expectFatal:           false, expectDelete:          true, expectOutputToContain: "node/node drained", </ins> }, { <del> description:  "pod with EmptyDir and --delete-emptydir-data", node:         node, expected:     cordonedNode, pods:         []corev1.Pod{emptydirPod}, args:         []string{"node", "--force", "--delete-emptydir-data=true"}, expectFatal:  false, expectDelete: true, </del> <ins> description:           "pod with EmptyDir and --delete-emptydir-data", node:                  node, expected:              cordonedNode, pods:                  []corev1.Pod{emptydirPod}, args:                  []string{"node", "--force", "--delete-emptydir-data=true"}, expectFatal:           false, expectDelete:          true, expectOutputToContain: "node/node drained", </ins> }, { <del> description:  "empty node", node:         node, expected:     cordonedNode, pods:         []corev1.Pod{}, rcs:          []corev1.ReplicationController{rc}, args:         []string{"node"}, expectFatal:  false, expectDelete: false, </del> <ins> description:           "empty node", node:                  node, expected:              cordonedNode, pods:                  []corev1.Pod{}, rcs:                   []corev1.ReplicationController{rc}, args:                  []string{"node"}, expectFatal:           false, expectDelete:          false, expectOutputToContain: "node/node drained", </ins> }, { description:                "fail to list pods",

Discussion:
When draining a node, using kubectl drain [NODE], the output resembles this: Expected output should indicate that the node was drained, for example: kubectl drain [NODE] No response <details</details<detailsCan reproduce locally using and printing the output </details<details</details<details</details<details</details<details</details
/sig cli
/triage accepted
Change:
return fmt.Sprintf("%dm", minutes) } else if hours := int(d.Hours()); hours < 24 { return fmt.Sprintf("%dh", hours) <del> } else if hours < 24*364 { </del> <ins> } else if hours < 24*365 { </ins> return fmt.Sprintf("%dd", hours/24) } return fmt.Sprintf("%dy", int(d.Hours()/24/365))

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): kubectl version Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-03-22T00:23:49Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-03-22T00:17:51Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} What happened: kubectl get namespace $NS NAME STATUS AGE $NS Active 0y Show 0y, a kubectl get namespace $NS-o=yaml apiVersion: v1 kind: Namespace metadata: creationTimestamp: 2016-04-18T07:37:18Z shows that its almost a year old now. What you expected to happen: Show 1y or 12m, 0y is a bit confusing. How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
let me take a look at it
A tiny issue in the printers, fixing it now
Change:
MatchExpressions: []metav1.LabelSelectorRequirement{}, }, }, <ins> { name:          "no resource and selector", args:          args{args: []string{}}, wantResources: []string{}, wantErr:       false, wantSelector:  nil, }, </ins> } for _, tt := range tests { gotResources, gotSelector, err := getResourcesAndSelector(tt.args.args)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one):BUG REPORT Kubernetes version (use ):Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2610+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-12-29T06:28:44Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2610+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-12-29T06:28:44Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"} What happened:
Could someone from please help with triage. Thanks!
There is already a PR on the way.
Change:
}, expectedTrace: []*spanExpectation{ { <del> name: "KubernetesAPI", </del> <ins> name: "PATCH /api/v1/nodes/{:name}", </ins> attributes: map[string]func(*commonv1.AnyValue) bool{ "http.user_agent": func(v *commonv1.AnyValue) bool { return strings.HasPrefix(v.GetStringValue(), "tracing.test")

Discussion:
When enable apiserver tracing, the webhook request spans only show spanName as /, mostly because use http request operations as default span name, which is hard to understand. ! Following the open-telemetry standard of spanName, it's recommended to use as spanName. ! SpanName of webhook request should be , like ! APIServerTracing feature gates of apiserver a pod tracing dashboard No response <details18 </details<detailsNone </details<details</details<details</details<details</details<details</details
I make a fix for this.
/sig api-machinery instrumentation
Do you know if this is fixed in later versions of opentelemetry?
/triage accepted /assign
Looks like might be related
not yet, I think we can fix this in otel upstream, but it's hard to backport to otel , which is the version of otel used in Kubernetes
Good point. It think fixing it here is a good idea in that case.
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]:
/remove-lifecycle stale
could I take on this issue?
yes. Feel free to work on this.
! I test locally by 1.29 kubernetes and start a sample webhook, looks like the client span has already conforms to semantic conventions , which should be in the form of "HTTP {METHODNAME}"
! For apiserver as a server, now the spanName is still KubernetesAPI, which I think we could enhance it into "HTTP get_account/{accountId}" format
After digging for a while, I found one solution to implement this, I draft this idea in , could you help review about whether this is a correct way to implement it?
Change:
It("should spread the pods of a replication controller across zones", func() { SpreadRCOrFail(f, int32((2*zoneCount)+1), image) }) <ins> It("should schedule pods in the same zones as statically provisioned PVs", func() { PodsUseStaticPVsOrFail(f, (2*zoneCount)+1, image) }) </ins> }) // Check that the pods comprising a service get spread evenly across available zones

Discussion:
For statically created PVs, the persistent volume label admission controller adds the zone label to the PV object. If the admission controller is not enabled or has some bugs, then an e2e test would be helpful for catching these errors. /assign
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 and label list
Change:
storagev1 "k8s.io/api/storage/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" <ins> "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" </ins> types "k8s.io/apimachinery/pkg/types" utilerrors "k8s.io/apimachinery/pkg/util/errors" "k8s.io/apimachinery/pkg/util/uuid"

Discussion:
[x] test approval issue : [x] test pr : [x] Flake [x] two weeks soak end date : 31 Oct 2023 [X] test promotion pr : [X] remove endpoint from According to following APIsnoop query, there are three PersistentVolume and three PersistentVolumeClaim endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 6 endpoints. The e2e logs for this test are listed below. This query shows the following PV and PVC endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 6 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted /cc
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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