jiebi/CodeConvo huggingface dataset:
Change:
cpu: "2" memory: 1Gi min: <del> cpu: 250m </del> <ins> cpu: 200m </ins> memory: 6Mi type: Pod - default: <del> cpu: 250m </del> <ins> cpu: 300m memory: 200Mi defaultRequest: cpu: 200m </ins> memory: 100Mi max: cpu: "2" memory: 1Gi min: <del> cpu: 250m memory: 6Mi </del> <ins> cpu: 100m memory: 3Mi </ins> type: Container

Discussion:
Since resource QoS is implemented, limitrange also supports request constraint, we can add an example for that.
cc
Change:
var ignoreNotReady bool badPods := []v1.Pod{} desiredPods := 0 <ins> notReady := int32(0) </ins> if wait.PollImmediate(Poll, timeout, func() (bool, error) { // We get the new list of pods, replication controllers, and

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup What happened: This log seems to imply that we wait until less than some number of pods are un-ready, and yet the loop succeeds if there is no improvement. What you expected to happen: Either the loop should terminate earlier (if the condition is acceptable) or fail (if it's unacceptable).
/sig scalability since this probably most affects us
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. 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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
return class }(), }, <ins> "good-parameters-apigroup": { class: func() *resource.ResourceClass { class := testClass(goodName, goodName) class.ParametersRef = goodParameters.DeepCopy() class.ParametersRef.APIGroup = goodAPIGroup return class }(), }, "bad-parameters-apigroup": { wantFailures: field.ErrorList{field.Invalid(field.NewPath("parametersRef", "apiGroup"), badAPIGroup, "a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')")}, class: func() *resource.ResourceClass { class := testClass(goodName, goodName) class.ParametersRef = goodParameters.DeepCopy() class.ParametersRef.APIGroup = badAPIGroup return class }(), }, </ins> "missing-parameters-name": { wantFailures: field.ErrorList{field.Required(field.NewPath("parametersRef", "name"), "")}, class: func() *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
Change:
func initStatusForbiddenControlPlaneConfig() *controlplane.Config { controlPlaneConfig := framework.NewIntegrationTestControlPlaneConfig() <ins> controlPlaneConfig.GenericConfig.Authentication.Authenticator = authenticatorunion.New( authauthenticator.RequestFunc(func(req *http.Request) (*authauthenticator.Response, bool, error) { return &authauthenticator.Response{ User: &user.DefaultInfo{ Name:   "unprivileged", Groups: []string{user.AllAuthenticated}, }, }, true, nil })) </ins> controlPlaneConfig.GenericConfig.Authorization.Authorizer = authorizerfactory.NewAlwaysDenyAuthorizer() return controlPlaneConfig }

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/kind flake <!-- Please assign a SIG using: /sig SIG-NAME --/sig api-machinery
/assign I want to take a try
2 but actual 0 till timeout resource services, expected 2, actual 0 error waiting or ResourceQuota status: timed out waiting for the condition time later, actual state became 2 Seems polls a ResourceQuota status with timeout 10s may be not enough, we should enlarge it into 300s, that is poll for 300s timeout instead of 10s.
/triage accepted
Change:
export ARTIFACTS_DIR=${WORKSPACE}/artifacts # Save the verbose stdout as well. export KUBE_KEEP_VERBOSE_TEST_OUTPUT=y <del> export KUBE_TIMEOUT='-timeout 300s' </del> export KUBE_INTEGRATION_TEST_MAX_CONCURRENCY=4 export LOG_LEVEL=4

Discussion:
/kind test-flake https://k8s-
/kind flake
cc
Saw this on
Sorry, I haven't had time to look into this. Let's see if can get to this earlier than I do.
I'm seeing this a lot in the rush to code freeze.
if this is actually a 1.10 bug, can you add status/approved-for-milestone to it? Thanks.
Something suspicious from the , but probably it's not related to the failure:
The garbage collector's behavior looks right, it does delete the dependent configmap: The tested start at 16:44:27., and failed with "test timed out after 5m0s" at 16:44:50.. I'll check if other failed cases have the same causes.
The "Kubernetes Aggregated Failures" shows there is no "TestCRDDeletionCascading" failure in the last tests (). Maybe I used the wrong tool? cc
cc because triage does not support pull-kubernetes-unit? I cannot find in as well
gave a new failure sample: https://k8s- (And the triage dashboard can't find it). Anyway, the test showed similar behavior. The tested started at I0226 20:57:02.. The gc behaved correctly: And the 5min timeout occurred 23s after the test began. I'll check what's the 5min timeout for.
The 5 min timeout is for all the tests in the test/integration/garbagecollector package. The tests are run sequentially, so is the last one to run, and unfortunately uses up the 5 min quota. The two logs I looked into showed the test itself was healthy. We just need to increase the timeout limit for this package.
found a lot of failure samples here: https://k8s- The first 11 of them failed because the 5m timeout.
Indicates this is still present and severe.
I was trying to get recent failures, it seems we recently moved intergration tests out of the unit test suites, https://k8s-, where there is no failure yet. I'll try again tomorrow.

(we rename the job this afternoon, it was named kubernetes-unit but only runs integration test)
https://k8s- that looks all green so far
Can we also check run time of the tests in that package over the past couple weeks? It seems like this just spiked. Did our tests slow down, or did we add tests to that package?
as far as I can tell the runtime of the test didn't spike ( shows the test running in just over 300s and also included the original bump of the timeout from 300s to 600s), but the timeout was accidentally decreased from 600s back to 300s as an unintended side effect of
ah, ok
Since it has passed the last 26 times, is this safe to reclose?
/close
Change:
mounter := mount.New() if s.Containerized { glog.V(2).Info("Running kubelet in containerized mode (experimental)") <del> mounter = &mount.NsenterMounter{} </del> <ins> mounter = mount.NewNsenterMounter() </ins> } var dockerExecHandler dockertools.ExecHandler

Discussion:
What happened: Windows documentation claims: V1.VolumeMount.mountPropagation - only MountPropagationHostToContainer is available. However, the internals suggest otherwise; is always returned on Windows: Either the docs should be corrected, or the Kubelet should be updated, or we should have a comment on why this does in fact enable MountPropagationHostToContainer on Windows. /cc /sig windows
/cc
/cc
I think the doc is not accurate. The doc claims the same thing. For MountPropagationHostToContainer option, we can test it whether it is working or not.
i created two PRs to address the documentation gap. we will also test this and get back to this thread.
For 1.15 we may need to update Kubelet code to allow HostToContainer.
Change:
NodeName:            c.NodeName, KubeletPort:         c.KubeletPort, KubeletReadOnlyPort: c.KubeletReadOnlyPort, <del> MaxPods:             maxPods, </del> <ins> MaxPods:             c.MaxPods, </ins> PodsPerCore:         podsPerCore, NodeLabels:          c.NodeLabels, RegisterWithTaints:  c.RegisterWithTaints,

Discussion:
A kubernetes cluster is normally constructed from a variety of machine templates. Different instance groups may have different CPU, memory capacity. They may be equipped with specialized accelerators, network devices. I think we should have an extensible way for users to custom node configuration to simulate real production cluster states. Currently, nodelabel and nodetaints are supported. I am consider to accept a template with more configuration like resources so we won't grow option list in the future. Without this feature, it's hard for users to simulate heterogeneous cluster.
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
/sig scalability
Change:
in case that it needs that for operations like error injection or checking calls. <del> ## Cluster setup </del> <ins> ## Cluster setup preparation </ins> <del> The container runtime must support CDI. The latest cri-o releases contain support, containerd 1.6.x does not. To bring up a kind cluster with containerd built from their main branch, use: </del> <ins> The container runtime must support CDI. CRI-O supports CDI starting from release 1.23, Containerd supports CDI starting from release 1.7. To bring up a Kind cluster with Containerd, two things are needed: - [build binaries from Kubernetes source code tree](https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#building-kubernetes) - [Kind](https://github.com/kubernetes-sigs/kind) </ins> <del> - [Bash version requirement](https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#bash-version-requirement) </del> <ins> > NB: Kind switched to use worker-node base image with Containerd 1.7 by default starting from release 0.20, build kind from latest main branch sources or use Kind release binary 0.20 or later. </ins> <del> - Build node image </del> <ins> ### Build kind node image After building Kubernetes, in Kubernetes source code tree biuld new node image: </ins> ```bash <del> $ test/e2e/dra/kind-build-image.sh dra/node:latest </del> <ins> $ kind build node-image --image dra/node:latest $(pwd) </ins> ``` <del> - Bring up a kind cluster </del> <ins> ## Bring up a Kind cluster </ins> ```bash $ kind create cluster --config test/e2e/dra/kind.yaml --image dra/node:latest ```

Discussion:
uses containerd for worker nodes by default, and latest release of uses by default base-image with containerd 1.6 for worker node. Unfortunately, CDI was merged into containerd 1.7, and CI at the moment uses binary from unreleased build 0.20-alpha. So running e2e tests locally for is failing unless when building node image a parameter is used with base-image that has 1.7 containerd. The need needs to be mentioned in DRA e2e Dynamic Resource Allocation e2e work locally when running them according to the instruction. Run DRA e2e with kind 0.19. The fix is coming shortly. 27, 1.28-alpha N/A N/A N/A N/A N/A
/sig node /assign
/triage accepted
I recommend testing kubernetes @ HEAD with KIND @ HEAD more generally. Nearly all of Kubernetes CI does this, we can't guarantee that a previously released binary has fixes to handle unreleased kubernetes breaking changes so periodically this is required regardless of this specific issue.
Alright, that recommendation was not noticed by me unfortunately. And thinking that there might be more like me, let's at least document it in the DRA e2e tests README.
Change:
"uniqueItems": true }, { <del> "description": "Redirect the standard error stream of the pod for this call. Defaults to true.", </del> <ins> "description": "Redirect the standard error stream of the pod for this call.", </ins> "in": "query", "name": "stderr", "type": "boolean",

Discussion:
As per the PRs kubernetes/kubernetes kubernetes/kubernetes, the defaulting behaviour of the pod exec parameters had been changed however in the code there is a comment where it is mentioned it defaults to True The comment about the default value must be removed and the openapi spec must be fixed Present in the file as comment and also in the OpenApiSpec swagger If this issue seems appropriate can I take it up please <details</details<details</details<details</details<details</details<details</details<details</details
/sig docs
/sig node
/assign
/assign
/help /triage accepted
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 /triage accepted </details
/kind documentation
Change:
verbs:          "get", nonResourceURL: "/logs/,/healthz", expectedClusterRole: &rbac.ClusterRole{ <ins> TypeMeta: v1.TypeMeta{APIVersion: "rbac.authorization.k8s.io/v1", Kind: "ClusterRole"}, </ins> ObjectMeta: v1.ObjectMeta{ Name: clusterRoleName, },

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?: /kind bug What happened: Upgraded Kubectl to version 1.10.0 and now the flag on the creation of a docker-registry secret doesn't print out resulting in the following error: What you expected to happen: I expect the output to have a attribute in the YAML output. How to reproduce it (as minimally and precisely as possible): Here is an example you can run in bash of this not working: The output is: My exact shell code I'm running on the CI server is this Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: 3 on AWS managed with KOPS OS (e.g. from /etc/os-release): Alpine Linux on my CI server, MacOS on my main machine Kernel (e.g. ): Darwin Kernel Version 17.4.0
/sig CLI
cc
/status approved-for-milestone
/assign
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
fyi
The issue appears to be with the command, not with : Will look into this
fix is in
No, the output of is missing kind/apiVersion.
thanks, just saw the PR
Change:
// Querying a non-existent dummy disk on the datastore folder. // It would fail and return an folder ID in the error message. _, err := dc.GetVirtualDiskPage83Data(ctx, dummyDiskVolPath) <ins> canonicalVolumePath, err = getPathFromFileNotFound(err) </ins> if err != nil { <del> re := regexp.MustCompile("File (.*?) was not found") match := re.FindStringSubmatch(err.Error()) canonicalVolumePath = match[1] </del> <ins> return "", fmt.Errorf("failed to get path from dummy request: %v", err) </ins> } } diskPath := vclib.GetPathFromVMDiskPath(canonicalVolumePath)

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!--What happened: Provsioning a PVC using a storage class with vSphere as the cloud provider failed with error "runtime error: index out of range". What you expected to happen: The PVC should have been created. How to reproduce it (as minimally and precisely as possible): Create a PVC using a storage class with vSphere as the cloud provider and a VMware vCenter Server where the default language is not English. Anything else we need to know?: K8s in conjunction with vSphere PVC relies on English error messages from the VMware API in order to determine the canonical path for a newly created volume (VMDK file). The faulting code (v1.11.3, still the same on master) can be found here (starting at line 312): The line "canonicalVolumePath = match[1]" (340) in the above code is the problem because "File (.*?) was not found" (English) never matches for a different language (e.g. German: "Datei [DATASTORE] kubevols/kube- wurde nicht gefunden") and a “runtime error: index out of range” oocurs in the "kube-controller-manager". This causes the already created volume (VMDK file) not to be reported back to the K8s system which in turn will try to recreate it repeatedly in a loop (fails with "Cannot complete the operation because the file or folder [DATASTORE] /kubevols/kubernetes-dynamic-pvc-[UUID] already exists"). Find below the corresponding log excerpt (kube-controller-manager): Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vSphere OS (e.g. from /etc/os-release): n/a Kernel (e.g. ): n/a Install tools: n/a Others: n/a <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign
Change:
testSvcLabels := map[string]string{"test": "response"} framework.Logf("Creating pod...") <del> _, err := f.ClientSet.CoreV1().Pods(ns).Create(context.TODO(), &v1.Pod{ </del> <ins> pod := &v1.Pod{ </ins> ObjectMeta: metav1.ObjectMeta{ <del> Name: "agnhost", </del> <ins> Name:      "agnhost", Namespace: ns, </ins> Labels: map[string]string{ "test": "response"}, },

Discussion:
pull-kubernetes-e2e-kind-ipv6 - Not sure. Time out on waiting Pod to be started. No response /sig network
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
Change:
return name, volumeOptions.CapacityGB, labels, fstype, nil } <ins> // getCandidateZones finds possible zones that a volume can be created in func getCandidateZones(cloud *aws.Cloud, selectedNode *v1.Node) (sets.String, error) { if selectedNode != nil { // For topology aware volume provisioning, node is already selected so we use the zone from // selected node directly instead of candidate zones. // We can assume the information is always available as node controller shall maintain it. return sets.NewString(), nil } // For non-topology-aware volumes (those that binds immediately), we fall back to original logic to query // cloud provider for possible zones return cloud.GetCandidateZonesForDynamicVolume() } </ins> // returns volumeOptions for EBS based on storageclass parameters and node configuration func populateVolumeOptions(pluginName, pvcName string, capacityGB resource.Quantity, tags map[string]string, storageParams map[string]string, node *v1.Node, allowedTopologies []v1.TopologySelectorTerm, zonesWithNodes sets.String) (*aws.VolumeOptions, error) { requestGiB, err := volumehelpers.RoundUpToGiBInt(capacityGB)

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: We have pretty large clusters in aws and in production, we found an inefficiency in provisioning dynamic EBS volumes, where aws-ebs volume provisioner tries to look for available zone from aws directly. With scale, this can trigger massive from ec2, and affect cluster stability. This is also related to What you expected to happen: To simply get zones with available instances, we can get information from API server for efficiency. There might be a delay between node gets shutting down and such change is reflected in api server, but in case node is not ready or gets terminated, there will be higher level reconciliation triggered so we are safe. How to reproduce it (as minimally and precisely as possible): We only expect this to be hit when the cluster is huge (or aws account is huge) so not easy to reproduce. /assign /sig aws /sig cloud-provider
/assign
Change:
func TestValidate(t *testing.T) { tests := map[string]struct { <del> ranges []extensions.GroupIDRange groups []int64 pass   bool </del> <ins> ranges        []extensions.GroupIDRange groups        []int64 expectedError string </ins> }{ "nil security context": { ranges: []extensions.GroupIDRange{ {Min: 1, Max: 3}, }, <ins> expectedError: "unable to validate empty groups against required ranges", </ins> }, "empty groups": { ranges: []extensions.GroupIDRange{ {Min: 1, Max: 3}, }, <ins> expectedError: "unable to validate empty groups against required ranges", </ins> }, "not in range": { groups: []int64{5},

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: This is request for improvements. What happened: When PodSecurityPolicy provider validates or fields of a pod, it shows an error like "999 is not an allowed group" if the group doesn't belong to the range(s). What you expected to happen: It should include to the error message also the allowed values -- the ranges against what we were validating this group. This will simplify user experience and debugging. How to reproduce it (as minimally and precisely as possible): run kubernetes cluster with PSP support create a PSP that allows fsGroup/SupplementalGroups in some ranges grant to a user access to this PSP try to create a pod that has fsGroup/SupplementalGroups outside of the allowed ranges Anything else we need to know?: In order to improve the current behavior, we need to modify function here: Reported-by: /kind help
This looks like a good first issue! My suggestion would be something like . I would also suggest to merge overlaying ranges in the log message, like as , to keep the log as concise as possible. I will look into it.
Maybe something like ? Thank you!
We can use the same approach that strategy uses:
Sure, that is probably the most consistent solution.
/remove-help