jiebi/CodeConvo huggingface dataset:
Change:
"Time": recent(maxStatsAge), // We don't limit system container memory. "AvailableBytes":  BeNil(), <del> "UsageBytes":      bounded(100*framework.Kb, 10*framework.Gb), "WorkingSetBytes": bounded(100*framework.Kb, 10*framework.Gb), "RSSBytes":        bounded(100*framework.Kb, 1*framework.Gb), </del> <ins> "UsageBytes":      bounded(100*framework.Kb, memoryLimit), "WorkingSetBytes": bounded(100*framework.Kb, memoryLimit), "RSSBytes":        bounded(100*framework.Kb, memoryLimit), </ins> "PageFaults":      bounded(1000, 1E9), "MajorPageFaults": bounded(0, 100000), })

Discussion:
/kind bug What happened: e2e node summary test fails on machines with more than 10Gb of ram. What you expected to happen: memory limit bounds to look at node capacity rather than hardcode an upper bound. How to reproduce it (as minimally and precisely as possible): have more ram on a box and run e2e-node FOCUS=Summary Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig node
Change:
package validation import ( <ins> "fmt" </ins> "github.com/robfig/cron" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

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: Deployed an cronJob with an empty and it defaulted to which is an invalid option: Leaving the key out completely has the same result What you expected to happen: The empty key to default to something valid like or . Also document what this default is, my proposal would be to have as default since some tasks can't be reran easily. But it might be nice to force as default to enforce the stateless mindset even for crons :) How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: I guess not but I am open for questions :) Environment: Kubernetes version (use ): 1.19.2
My guess would be /sig api-machinery If it is better practice to wait for the triage instead of guessing the sig, let me know :+1:
/sig api-machinery
/assign
/remove-sig api-machinery /sig apps
/assign
/triage accepted
Change:
if err != nil { return fmt.Errorf("rbd: failed to unmap device %s:Error: %v", device, err) } <ins> // load ceph and image/pool info to remove fencing if err := util.loadRBD(&rbd, mntPath); err == nil { // remove rbd lock util.defencing(rbd) } </ins> glog.Infof("rbd: successfully unmap device %s", device) } return nil

Discussion:
etcd cluster backing apiserver died spontaneously, after restart apiserver pulled up the pods on different machines. Node storage was backed by ext4 over rbd, which became mounted on several nodes at once. That could have possibly led to data corruption. I guess that the proper way to mount rbd volume is to take a lock on it first, which will at least fail if it's locked somewhere else, requiring manual intervention, but not destroying data. The lock should be optional, in case a proper cluster fs is mounted over the rbd. In this case there was clearly no need for accessing the data from several pods so ext4 is deemed a proper fs.
, Vladimir Pouzanov < :
want to get some detail. How is your pod-to-rbd mapping like? Since rbd image is a block device, it can be used by one pod at a time. I am not sure if locking is a proper way to go - if the pod holds a lock but dies in the middle of mounting, the rbd image (or any other volume type) is then excluded from access. In such case, a high level coordination at apiserver is a better place to resolve this problem.
Here's my rc: I guess it's better to have a lock to be cleaned up manually rather than to have non-cluster fs to be mounted in several locations at once?
thanks, this pod looks good to me. what would cause multiple nodes run the same pod?
I don't know the exact reason of why kubelet didn't unmount the old fs, but after apiserver and scheduler were restarted pod got allocated on different node.
It is a scary thing to see etcd down, it is meant to be reliable...
Unfortunately I don't have long-term logging in test cluster so I have no idea why it actually died. but using kubedns as primary node resolver was clearly a bad idea, once it died, nodes stuck with no resolver at all.
your thought on HA?
Wrong Tim St. Clair?
- you HAVE to be ready to handle network partitions - the old node might still be alive and even using the volume, but the apiserver can't see the node, so it thinks it deletes the pod and starts it elsewhere. If RBD corrupts itslef in this case, it is not useful and we should strip it from the codebase.

, Huamin Chen wrote:
that makes sense. rbd doesn't corrupt itself. This is inconsistency happens when you have two pods mounting the same rbd image. How does GCE PD handle/prevent this case?
It doesn't allow more than one read-write attachment. Multiple read-only attachments is OK. Better to fail than to allow corruption. , Huamin Chen wrote:
That's neat. I have a lock fencing for rbd, testing now.
Change:
var lastMetricsFetchErr error if metricsWaitErr := wait.PollImmediate(time.Second, time.Minute, func() (bool, error) { <del> _, lastMetricsFetchErr = g.getMetricsFromPod(g.client, metricsProxyPod, metav1.NamespaceSystem, kubeControllerManagerPort) </del> <ins> output, lastMetricsFetchErr = g.getMetricsFromPod(g.client, metricsProxyPod, metav1.NamespaceSystem, kubeControllerManagerPort) </ins> return lastMetricsFetchErr == nil, nil }); metricsWaitErr != nil { err = fmt.Errorf("error waiting for controller manager pod to expose metrics: %v; %v", metricsWaitErr, lastMetricsFetchErr)

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:
// If version is not supported, the assertion fails with an error. // This test should be done early during the storage operation flow to avoid // unnecessary calls later. <ins> // `ver` argument holds the expected supported version. </ins> func (c *csiDriverClient) AssertSupportedVersion(ctx grpctx.Context, ver *csipb.Version) error { if c.versionAsserted { if !c.versionSupported {

Discussion:
/kind bug What happened: When a CSI driver reports a version of the CSI spec which does not match that stored in Kubernetes, Kubernetes prints the following message: What you expected to happen: Message should be: How to reproduce it (as minimally and precisely as possible): Use a CSI driver that reports version 0.0.0. Then deploy an application pod with a PVC from this driver. Application pod description will show the actual message above. Environment: Kubernetes version (use ): 1.9.1
/sig storage
/assign lpabon
hi, I can help fix that.
I did not see your PR until after I submitted.
Change:
if err != nil { return nil, err } <ins> if !tpExists { glog.Infof("Target pool %v for Service %v/%v doesn't exist", loadBalancerName, apiService.Namespace, apiService.Name) } </ins> // Now we get to some slightly more interesting logic. // First, neither target pools nor forwarding rules can be updated in place -

Discussion:
Restarting master causes a recreation of fwrule and target pool for type=loadbalancer services. We are saved in the non restart case because we compare a cached verson of the service to decided if we should even call into the cloudprovider and update resources. This is happening because our reconciliation routines are confused about session affintiy and lbip, leading them to recreate, since inplace update isn't allowed. The impact is at best a few seconds of radio silence, at worst who knows? Repro: Create a loadbalanced service, eg: Wait for it to acquire a vip. Try it out Ssh into master and restart kube-controller-manager: Watch the wgets, you'll notice radio silence after a bit. This is because the targetpool and forwarding rule get recreted, for 2 reasons: affinity mismatch So this check fails: Lbip mismatch: So this check fails: (lbip is retrieved here: )
the session affinity fix is trivial. The easiest change for the lb ip fix is to not actually check the ip, but simply backoff as long as the forwarding rule exists. This is "bad" because of the way we allocate a static-ip, assign it to the fwd rule, then de-allocate it. The alternative is to use to reconcile, but that's racy.
cherry pick
Change:
if !found { return nil, fmt.Errorf("'name' is a required parameter.") } <del> port, err := strconv.Atoi(params["port"]) </del> <ins> portString, found := params["port"] if !found { return nil, fmt.Errorf("'port' is a required parameter.") } port, err := strconv.Atoi(portString) </ins> if err != nil { return nil, err }

Discussion:
expose hostnames --port=80 --container-port=9376 --selector="app=hostnames" get se hostnames -o yaml apiVersion: v1beta1 containerPort: "9376" ... obviously, endpoints controller is not happy.
Change:
Obj() inUseClaim = st.FromResourceClaim(pendingImmediateClaim). Allocation(&resourcev1alpha2.AllocationResult{}). <del> ReservedFor(resourcev1alpha2.ResourceClaimConsumerReference{UID: types.UID(podUID)}). </del> <ins> ReservedFor(resourcev1alpha2.ResourceClaimConsumerReference{Resource: "pods", Name: podName, UID: types.UID(podUID)}). </ins> Obj() allocatedClaim = st.FromResourceClaim(pendingDelayedClaim). OwnerReference(podName, podUID, podKind).

Discussion:
Apply this patch: Then run: This fails with: Test should pass. See above. If there are N objects in claims.Items, then this loop for _, claim := range claims.Items { objects = append(objects, &claim) } is appending the same pointer N times, pointing at the final item in the list. Adding fixes that mistake, but then it makes the test fail. Something else about the test is buggy, but the bug was being masked by this bug. In the repro case I to the loop a few lines down, just for good measure, but that one is not causing a problem. The line by itself causes the test failure. HEAD N/A N/A N/A N/A N/A
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 scheduling /priority important-soon /cc Thanks for finding this and the detailed report
/assign
Can you help to fix this?
If we don't here from soonish, then I'll fix it myself.
Sorry, I've been busy with an office accident this week, if you want fix it, please take it
/assign
/unassign
Change:
"k8s.io/client-go/tools/cache" "k8s.io/kubernetes/pkg/features" "k8s.io/kubernetes/pkg/scheduler/internal/queue" <ins> "k8s.io/kubernetes/pkg/scheduler/profile" </ins> ) func (sched *Scheduler) onPvAdd(obj interface{}) {

Discussion:
What happened: An extra scheduling attempt is observed in some scenarios when kube-scheduler already has already assumed a pod and this has entered the binding routine. If, during this time, a pod update is received, the pod is back to the scheduling queue, even if binding succeeds. This is the correct behavior, as scheduling conditions might change. However this updates could just be unrelated status updates, such as updates to pod conditions. We observe an extra scheduling attempt, which is visible in the log line: Which indicates that an attempt was made when the pod was already scheduled. What you expected to happen: No extra scheduling attempts How to reproduce it (as minimally and precisely as possible): This depends on other controllers running on the cluster that might report pod conditions. One such controller is
/sig scheduling
Change:
return cpuUsageNanoCores } <ins> func getSystemUUID() (string, error) { result, err := exec.Command("wmic", "csproduct", "get", "UUID").Output() if err != nil { return "", err } fields := strings.Fields(string(result)) if len(fields) != 2 { return "", fmt.Errorf("received unexpected value retrieving vm uuid: %q", string(result)) } return fields[1], nil } </ins> func getPhysicallyInstalledSystemMemoryBytes() (uint64, error) { // We use GlobalMemoryStatusEx instead of GetPhysicallyInstalledSystemMemory // on Windows node for the following reasons:

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: The windows kubelet does not set .status.nodeInfo.systemUUID on the node object. What you expected to happen: The windows kubelet sets the systemUUID from How to reproduce it (as minimally and precisely as possible): Start the windows kubelet and check for UUID: Anything else we need to know?: This will affect users running the out-of-tree vsphere CCM since that depends on the systemUUID, unlike the in-tree version. Also, looks like cAdvisor is the component responsible for providing the systemUUID so let me know if this issue needs to be moved to that repo. Environment: Kubernetes version (use ): Verified on 1.13.1 and 1.14 Cloud provider or hardware configuration: None OS (e.g: ): Windows Server 2019
/sig windows /sig vmware
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
/remove-lifecycle stale
Change:
expectedNodeInfo *NodeInfo }{ { <del> pod:         makeBasePod(t, nodeName, "non-exist", "0", "0", "", []v1.ContainerPort{{}}, []v1.Volume{}), </del> <ins> pod:         st.MakePod().UID("non-exist").Namespace("node_info_cache_test").Node(nodeName).Obj(), </ins> errExpected: true, expectedNodeInfo: &NodeInfo{ node: &v1.Node{

Discussion:
We have a pod fake function in , but this is not a base util anymore, we have a lot of arguments, we can replace this with here /sig scheduling /kind cleanup /help This is an easy one to get start. Cleaner code for maintenance.
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 : ### What would you like to be ? /kind cleanup /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
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
/remove-kind feature
I want to try this one, the problem we solve here is to replace the *v1.Pod with type PodWrapper {}? /assign
Replace with in
you mean replace ` in I check the code and didn't found out that we have makeBasePod in
I have tried it. But there will be error about cycle import, because package import package, where locate.
yes, I've tried it as well. guess I need to wait for kerthcet's response <img width="805" alt="image" src=""
Sorry, forgot to reply on this, I introduced another PR to help solve this import cycle, but waits for other maintainers' response. So generally, if that pr accepted, we can work on this one then. Thanks for the volunteer.
the import cycle is resolved, you can start your work now, thanks!
thanks for the ping!
Change:
fi } <ins> # Setup working directory for kubelet. function setup-kubelet-dir { echo "Making /var/lib/kubelet executable for kubelet" mount --bind /var/lib/kubelet /var/lib/kubelet/ mount -B -o remount,exec,suid,dev /var/lib/kubelet } </ins> function reset-motd { # kubelet is installed both on the master and nodes, and the version is easy to parse (unlike kubectl) local -r version="$("${KUBE_HOME}"/bin/kubelet --version=true | cut -f2 -d " ")"

Discussion:
GCI Test Failing: (kubernetes-gci-gce-alpha-features-release-1.4) ([] PetSet [Slow] [Feature:PetSet] [] Deploy clustered applications [Slow] [Feature:PetSet] should creating a working mysql cluster [Feature:PetSet]) https://k8s-
This one, and appear to be failing because of the same reasons. The files being written by the init containers don't have the right permissions perhaps? This is what I observed so far. Looks like it's mounted with noexec for some reason. cc
nice debug
Random tip, came across this looking for another bug. GCI broken emptydir because kubelet's root-dir is noexec. Petset is just a victim:
Seems to be a dup of I have posted a fix. , Prashanth B wrote:
Change:
" ## testsuite block <del> if [[ -e "$juDIR/junit-$suite.xml" ]]; then </del> <ins> if [[ -e "$juDIR/junit_$suite.xml" ]]; then </ins> # file exists. first update the failures count <del> failCount=`sed -n "s/.*testsuite.*failures="([0-9]*)".*/1/p" "$juDIR/junit-$suite.xml"` </del> <ins> failCount=`sed -n "s/.*testsuite.*failures="([0-9]*)".*/1/p" "$juDIR/junit_$suite.xml"` </ins> errors=$(($failCount+$errors)) <del> sed -i "0,/failures="$failCount"/ s/failures="$failCount"/failures="$errors"/" "$juDIR/junit-$suite.xml" sed -i "0,/errors="$failCount"/ s/errors="$failCount"/errors="$errors"/" "$juDIR/junit-$suite.xml" </del> <ins> sed -i "0,/failures="$failCount"/ s/failures="$failCount"/failures="$errors"/" "$juDIR/junit_$suite.xml" sed -i "0,/errors="$failCount"/ s/errors="$failCount"/errors="$errors"/" "$juDIR/junit_$suite.xml" </ins> # file exists. Need to append to it. If we remove the testsuite end tag, we can just add it in after. <del> sed -i "s^</testsuite>^^g" $juDIR/junit-$suite.xml ## remove testSuite so we can add it later sed -i "s^</testsuites>^^g" $juDIR/junit-$suite.xml cat <<EOF >> "$juDIR/junit-$suite.xml" </del> <ins> sed -i "s^</testsuite>^^g" $juDIR/junit_$suite.xml ## remove testSuite so we can add it later sed -i "s^</testsuites>^^g" $juDIR/junit_$suite.xml cat <<EOF >> "$juDIR/junit_$suite.xml" </ins> $content </testsuite> </testsuites>

Discussion:
is not picking the cmd test junit output due to file naming issue. The file name should match regex /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
/sig testing
Change:
return result, prefilterStatus.AsError() } <del> nodes := nodeLister.ListNodes() if err != nil { return result, err } if len(nodes) == 0 { </del> <ins> numNodes := g.cache.NodeTree().NumNodes() if numNodes == 0 { </ins> return result, ErrNoNodesAvailable }

Discussion:
In : It seems that nodes are only used in the case there are no predicates. This call can be moved inside . Moving it there saves us from creating the node slice unless it is necessary. Checking if there are no nodes (line 202 below) can be done using . /kind cleanup /sig scheduling
I can work on this
Change:
"net/http" "os" <del> v1 "k8s.io/api/core/v1" </del> "k8s.io/apimachinery/pkg/util/sets" kubeadmapi "k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm" "k8s.io/kubernetes/cmd/kubeadm/app/constants"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --https://k8s- kubeadm-init 06-22 https://k8s- all kubeadm jobs are failing against k/k master. is this failing after we merged?
cc /sig cluster-lifecycle /area kubeadm kinder cluster preparation constructs images locally by downloading tarballs and tagging them with: then running it would find the image locally and not pull it from GCR. does not contain pre-release images, so trying to pull these images would fail. i think the problem here is that we broke the default behavior with
ok, the problem is indeed here: empty string "" should be the same as PullIfNotPresent.
should be fixed by
/triage accepted
Change:
volSpec.Fstype = "ext4" } <ins> var volumeMode *v1.PersistentVolumeMode if utilfeature.DefaultFeatureGate.Enabled(features.BlockVolume) { volumeMode = v.options.PVC.Spec.VolumeMode if volumeMode != nil && *volumeMode == v1.PersistentVolumeBlock { glog.V(5).Infof("vSphere block volume should not have any FSType") volSpec.Fstype = "" } } </ins> pv := &v1.PersistentVolume{ ObjectMeta: metav1.ObjectMeta{ Name:   v.options.PVName,

Discussion:
FEATURE REQUEST: vSphere volume plugin does not support volume device yet. Need to add volumeMode in PV spec as other plugin did. release 1.12
/sig storage
Change:
kind: %s metadata: name: %s <del> finalizers: - test-finalizer </del> unknownField: unknown spec: foo: foo1

Discussion:
After running k8s conformance testing on kubernetes v1.27, we have leftover custom resources of the format that should not exist. For example) Basic test instructions: We use the latest official kubernetes kubekins image: We extract kubetest binary from kubekins latest-master docker image. We run serial conformance tests as follows. We also run parallel conformance tests as follows.
/sig api-machinery
The following script is used to cleanup the leftover CRDs:
/triage accepted /assign /cc
/area conformance
/sig architecture