jiebi/CodeConvo huggingface dataset:
Change:
Pod or delete and replace it with a new Pod release: v1.13 file: test/e2e/apps/rc.go <ins> - testname: Replication Controller, get and update ReplicationController scale codename: '[sig-apps] ReplicationController should get and update a ReplicationController scale [Conformance]' description: A ReplicationController is created which MUST succeed. It MUST succeed when reading the ReplicationController scale. When updating the ReplicationController scale it MUST succeed and the field MUST equal the new value. release: v1.26 file: test/e2e/apps/rc.go </ins> - testname: Replication Controller, release pods codename: '[sig-apps] ReplicationController should release no longer matching pods [Conformance]'

Discussion:
[X] Test approval issue: [X] Test PR: 29 Sept 2022 [X] Two weeks soak end date: 14 Oct 2022 [X] Test promotion PR: According to this APIsnoop query, there are still two remaining ReplicationControllerScale endpoints which are untested for conformance. readCoreV1NamespacedReplicationControllerScalereplaceCoreV1NamespacedReplicationControllerScale Using a number of existing e2e test practices a new has been created for two ReplicationControllerScale endpoints. The e2e logs for this test are listed below. This query shows which scale 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 2 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen 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:
// Fit is determined by resource availability algorithm.NewResourceFitPredicate(algorithm.StaticNodeInfo{nodes}), }, <del> // All nodes where things fit are equally likely (Random) algorithm.EqualPriority, </del> <ins> // Prioritize nodes by least requested utilization. algorithm.LeastRequestedPriority, </ins> &storeToPodLister{podCache}, r) podBackoff := podBackoff{

Discussion:
HPA tests are currently failing in gke-large cluster suite: I did some debugging and the problem seems to be related to pod-nanny. Looking into logs from the last run: was first scheduled on the large node dedicated to it pod-nany updated heapster deployment then heapster was scheduled on the normal node (when it actually shouldn't fit) that point it was never updated by the pod nanny. that point, heapster started crashlooping (OOMing) [which in fact was expected in too small machine] So it's pretty clear that that pod-nanny changed the amount of resources to something smaller, which in fact it shouldn't.
Change:
redirectHandler := &RedirectHandler{g.handler.storage, g.handler.codec} opHandler := &OperationHandler{g.handler.ops, g.handler.codec} <ins> servers := map[string]string{ "controller-manager": "127.0.0.1:10252", "scheduler":          "127.0.0.1:10251", // TODO: Add minion health checks here too. } validator, err := NewValidator(servers) if err != nil { glog.Errorf("failed to set up validator: %v", err) validator = nil } </ins> for _, prefix := range paths { prefix = strings.TrimRight(prefix, "/") proxyHandler := &ProxyHandler{prefix + "/proxy/", g.handler.storage, g.handler.codec}

Discussion:
If the scheduler is not healthy, pods won't schedule and things will get stuck in pending. Right now, there is no user visible feedback (in logs or events or pod status) that indicates that this is true. We should really have at least some logging in the apiserver, and possibly more in-depth information. I'm thinking that we should add a /validatez handler to the apiserver that does a quick sanity check. Added bonus: we could rip out all of the scripted health checking in the startup scripts.
A simple status HTTP page would be useful, showing the health status of each system component. We should seriously think about self-hosting, too. It doesn't seem like it would be hard to run a couple scheduler replicas using master election, managed by a replication controller.
Yeah, I think system components should register themselves with apiserver.
Change:
// ProbePodToPodConnectivity runs a series of probes in kube, and records the results in `testCase.Reachability` func ProbePodToPodConnectivity(k8s *kubeManager, model *Model, testCase *TestCase) { <del> numberOfWorkers := 30 </del> <ins> numberOfWorkers := 3 // See https://github.com/kubernetes/kubernetes/pull/97690 </ins> allPods := model.AllPods() size := len(allPods) * len(allPods) jobs := make(chan *ProbeJob, size)

Discussion:
Flakes in the past week: 4 Consistency: 78.90% /kind flake
the flakes should now be resolved by , can someone merge ? its a one character change. We just need an , has already reviewed it
/sig network
/triage accepted
Change:
if !reflect.DeepEqual(expected, update) { t.Errorf("Expected %#v, Got %#v", expected, update) } <ins> for i := range update.Pods { if errs := kubelet.ValidatePod(&update.Pods[i]); len(errs) != 0 { t.Errorf("Expected no validation errors on %#v, Got %#v", update.Pods[i], errs) } } } func TestSubdomainSafeName(t *testing.T) { type Case struct { Input    string Expected string } testCases := []Case{ {"/some/path/invalidUPPERCASE", "invaliduppercasa6hlenc0vpqbbdtt26ghneqsq3pvud"}, {"/some/path/_-!%$#&@^&*(){}", "nvhc03p016m60huaiv3avts372rl2p"}, } for _, testCase := range testCases { value := simpleSubdomainSafeHash(testCase.Input) if value != testCase.Expected { t.Errorf("Expected %s, Got %s", testCase.Expected, value) } value2 := simpleSubdomainSafeHash(testCase.Input) if value != value2 { t.Errorf("Value for %s was not stable across runs: %s %s", testCase.Input, value, value2) } } </ins> } // These are used for testing extract json (below)

Discussion:
The hash function generates names with upper-case letters, but the validation only allows lower-case. First, we clearly need a test for this. Second, we need to fix it. Should we allow upper-case characters (which the RFC does allow for DNS labels) or should we fix the hash? Allowing upper-case seems attractive, except that the RFC also says that case doesn't matter, but should be preserved "wherever possible". So we really have three choices, I see. a) only allow lower-case b) allow upper-case and always use caseless comparisons everywhere c) allow upper-case, but normalize to lower-case since it was your hash code
Re: test - sounds like a config source -config integration test, which I'll add. Re: hash - would argue we should fix the hash to generate lowercase for now. I think, but will double check, that the collision space is still improbably low for 63 lowercase chars. I can do that shortly.
And a validate test on all sources.
Lowercase would require base32, rather than base64, no? On Aug 3, 2014 8:20 AM, "Clayton Coleman" wrote:
Yeah, although I don't believe there's a difference to the outcome between base32 and base64(lowercase) given an appropriate hash function.
Well, base32 is reversible and a modified base64is not :) On Aug 3, 2014 9:00 AM, "Clayton Coleman" wrote:
Remind me again why reversibility is important? We discussed it in another issue but I can't find the context.
I'm going to change the generated name to which even with 2^8 files per host and a thousand hosts should be well below 0.% chance of collision
Its only important if we want to use it. We don't AFAIK. On Aug 3, 2014 9:34 AM, "Clayton Coleman" wrote:
Fix makes them unique, somewhat traceable (first 15 safe chars of the name), and generates base32 output.
Change:
import ( "bufio" "bytes" <ins> "encoding/json" </ins> "errors" "fmt" "io"

Discussion:
As a user if I a custom API resource (for example, a Fischer from the sample-apiserver), I can change the name in the metadata and I do not get a . Instead, a Patch to the new user-edited name is created, which can result in NotFound or even making changes to the wrong object. If I the object and change the metadata name (or kind or apiVersion), then it should be rejected by kubectl and no Patch performed. Run the sample-apiserver, and create a new object with name . Then do , and change the metadata name to , and save. You will either see a item not found (if test2 does not already exist), or you will accidentally edit . Slack discussion here: <details</details<details</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
/sig CLI
Change:
// Nvidia driver installation can take upwards of 5 minutes. driverInstallTimeout = 10 * time.Minute // Nvidia COS driver installer daemonset. <del> cosNvidiaDriverInstallerPath = "cluster/gce/gci/nvidia-gpus/cos-installer-daemonset.yaml" </del> <ins> cosNvidiaDriverInstallerUrl = "https://raw.githubusercontent.com/ContainerEngine/accelerators/stable/cos-nvidia-gpu-installer/daemonset.yaml" </ins> ) func makeCudaAdditionTestPod() *v1.Pod {

Discussion:
xref: /sig node /area test
I am working on this.
Can you update this with the types of tests that you are adding? Is this similar to ?
No, this is for running the existing GPU e2e tests on GKE which are currently running on only GCE.
The referenced PRs appear to have merged, closing.
Change:
for url in "${urls[@]}"; do local file="${url##*/}" rm -f "${file}" <del> if ! curl -f --ipv4 -Lo "${file}" --connect-timeout 20 --retry 6 --retry-delay 10 "${url}"; then </del> <ins> if ! curl -f --ipv4 -Lo "${file}" --connect-timeout 20 --max-time 80 --retry 6 --retry-delay 10 "${url}"; then </ins> echo "== Failed to download ${url}. Retrying. ==" elif [[ -n "${hash}" ]] && ! validate-hash "${file}" "${hash}"; then echo "== Hash validation of ${url} failed. Retrying. =="

Discussion:
We should track how often such failures happen. cc
Thanks for filing the issue. Looks like the node stuck at downloading our binary. Here is what I found at startup script: Apr 13 14:25:48 kubemark-5-master startupscript: Downloading binary release tar () ... Anything change lately with our startup script?
I even don't know who to ask... ?
Looks like is not retrying correctly
Thanks Mike! Agree with Dawn and Mike that this looks more like a node or cluster issue than test infra.
Change:
volumeMounts = append(volumeMounts, v1.VolumeMount{Name: volumename, MountPath: "/mnt/" + volumename}) } <del> volumes[volumeIndex] = v1.Volume{Name: volumename, VolumeSource: v1.VolumeSource{PersistentVolumeClaim: &v1.PersistentVolumeClaimVolumeSource{ClaimName: pvclaim.Name, ReadOnly: false}}} </del> <ins> volumes[volumeIndex] = v1.Volume{Name: volumename, VolumeSource: v1.VolumeSource{PersistentVolumeClaim: &v1.PersistentVolumeClaimVolumeSource{ClaimName: pvclaim.Name, ReadOnly: podConfig.PVCsReadOnly}}} </ins> volumeIndex++ } for _, src := range podConfig.InlineVolumeSources {

Discussion:
What happened: Running two pods that use the same iSCSI volume, one of them fails with: What you expected to happen: Both pods should be running Anything else we need to know?: It's caused by iscsi volume plugin persiting iSCSI settings into the mount directory itself (e.g. ): volume plugin creates the global mount directory. volume plugin creates there. volume plugin mounts the volume there. This shadows the file, but it's fine, as long as no other pod uses the same volume on the same node. creates a second pod that uses the volume. volume plugin tries to create in the global volume directory. Since the volume is mounted, it will either writes the file to the volume (!) or fails, if the volume is read-only.
/sig storage /assign /priority impotant-soon
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig storage /assign /priority impotant-soon 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 important-soon
Our e2e did not catch this, because they always create only one pod when testing read-only volumes.
Change:
hostPath: path: /dev containers: <del> - image: "gcr.io/google-containers/nvidia-gpu-device-plugin@sha256:5e3837c3ab99e90d4c19053998ad86239591de4264bc177faad75642b64b723d" </del> <ins> - image: "gcr.io/google-containers/nvidia-gpu-device-plugin@sha256:0e79da6998a61257585e0d3fb5848240129f0fa5b4ad972dfed4049448093c33" </ins> command: ["/usr/bin/nvidia-gpu-device-plugin", "-logtostderr"] name: nvidia-gpu-device-plugin resources:

Discussion:
This issue is here to satisfy PR requirements of issue association. A lot of times we need to do version bumps for minor bug fixes that don't deserve a separate issue in the kubernetes/kubernetes repo. /kind bug /sig node
/lifecycle frozen
all the linked PRs are emrged and no activity since more than 3 years /close
Closing this issue. <detailsIn response to : all the linked PRs are emrged and no activity since more than 3 years /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:
} // assignPod assigns the given pod to the given machine. <del> func (r *BindingREST) assignPod(ctx api.Context, podID string, machine string) error { _, err := r.setPodHostTo(ctx, podID, "", machine) if err != nil { return err </del> <ins> func (r *BindingREST) assignPod(ctx api.Context, podID string, machine string, annotations map[string]string) (err error) { if _, err = r.setPodHostAndAnnotations(ctx, podID, "", machine, annotations); err != nil { err = etcderr.InterpretGetError(err, "pod", podID) err = etcderr.InterpretUpdateError(err, "pod", podID) if _, ok := err.(*errors.StatusError); !ok { err = errors.NewConflict("binding", podID, err) } </ins> } <del> return err </del> <ins> return </ins> } type podLifecycle struct{}

Discussion:
Recap of related tangent in follows. Use case: I need to implement mesos task reconciliation in the kubernetes-mesos scheduler. If it crashes and then restarts, I want to be able to recover things like taskID, slaveID, offerID, etc. so as to rebuild the internal state of the scheduler. Once state is recovered, I can reconcile the against the tasks that the mesos master knows about. If I can't use binding annotations for this, then I need to store state some other (super inconvenient) way. Currently the etcd registry assignPod() implementation drops binding annotations on the floor. It should not, and instead they should be preserved for later access. Proposal: Store binding-related annotations in a new field: Pod.Status.Annotations When setting Pod.Status.Host="{some-host-name}" via assignPod(), binding annotations are copied in from Binding When cloning Pod.Status.Host in UpdatePod() (for an already-scheduled pod), the Pod.Status.Annotations are also cloned. I don't think /bindings has to be a readable apiserver endpoint, as long as the binding metadata is exposed some other way, as proposed above. I'd also like to propose that once binding annotations are "bound" to Pod.Status they become read-only. So they're essentially write-once, just like Pod.Status.Host is meant to be. cc xref
There is one situation where we probably want to clear Host, actually: in the case that the pod can't actually be materialized on the selected node for some reason, such as .
Any objection to a PR implementing my proposal? I'm happy to do the work.
You'll probably want to do it on top of (or after it lands) since that code path is changing significantly.
Though it is also represented in PodStatus, Host is properly a field in the PodSpec. Status must be completely reconstructable based on observations. The proposed Pod.Status.Annotations would not be. Furthermore, I don't think we should introduce another annotations field to Pod. I'd prefer to add a podAnnotations field to Binding, and then merge them into the pod. As for clearing the annotations, I'd prefer to simply fail a pod that was rejected by a node so as not to have to deal with that. Also note the discussion here re. moving binding to a pod subresource:
See also .
Change:
import ( "fmt" <ins> "net" "strconv" </ins> utilipvs "k8s.io/kubernetes/pkg/util/ipvs" )

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: IPVS real server can't be right deleted in FakeIPVS for ipvs testing. What you expected to happen: When delete ipvs real server, we can't give the weight information, so we can't use deep equal in .
/sig network /area ipvs
/kind bug
Change:
compute "google.golang.org/api/compute/v1" <ins> "k8s.io/client-go/tools/cache" </ins> appsv1 "k8s.io/api/apps/v1" v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Discussion:
[x] Original approval issue: [x] Two weeks soak end date: This issue is created to allow edit by /wip /hold This issue proposes the writing of a new test for the API endponts , , , with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to this APIsnoop query, there are still some remaining Endpoints endpoints which are untested. a Service in a namespace all Endpoints in all Namespaces find the created Service(1) /update the Namespaced Endpoint for the Service(1) the Namespaced Endpoint for the Service(1) the Namespaced Endpoint for the Service(1) Namespaced Endpoint(1) via a Collection with a LabelSelector Discover useragents: If a test with these calls gets merged, Conformance coverage will go up by 4 points* /sig testing /sig architecture /area conformance
/reopen Wait for Promotion PR to Merge.
Reopened this issue. <detailsIn response to : /reopen Wait for Promotion PR to Merge. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
import ( "fmt" "reflect" <ins> "strings" </ins> ) // Equalities is a map from type to a function comparing two values of

Discussion:
This tree has a commit that demonstrates two obviously different objects that should not pass the semantic DeepEqual but do.
What shall we do with this issue for triage? Labels? Priority?
P2 for when he returns , Satnam Singh wrote:
OK I am now sufficiently worried about this. Fixes incoming.
Change:
"github.com/coreos/go-systemd/v22/daemon" "github.com/spf13/cobra" "github.com/spf13/pflag" <ins> "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/metric/noop" </ins> "google.golang.org/grpc/codes" "google.golang.org/grpc/status" jsonpatch "gopkg.in/evanphx/json-patch.v4"

Discussion:
Since updating from Kubernetes 1.26. to 1.29. we experiences OOM-Kills on control plane nodes. After some investigation we found that adding to the fixed the issue. (Found this via pprof/heap of one apiserver: heap dump could be if needed) Before the update to 1.29.* the control planes were running with 4GB of memory with the same worklow in the cluster without issues. After the workarround using the feature gate the memory consumption of the whole control plane is not at ~2GB. In case there is an issue with other components, memory consumption of the apiserver should not be that excessive. We just had the K8s cluster running and saw a permant increase in memory usage of the control plane nodes. And after some time (can not give a specific duration) the OS of the control plane node started to OOM kill processes. Let us know if you need additional information. <details</detailson-premise; control-planes are running with 4 CPU cores, 8GB of memory and and NVME discs <details</details<details</details<details</detailsNo response
/sig api-machinery
Please provide the pprof, and what is the size of your cluster.
As we were not sure if sharing the pprof is secure, we decided to only share screenshots first: ! ! From this information we found the this which pointed us to the mentioned feature flag. We sometimes see etcd connection timeouts in the apiserver logs, maybe this could be related but should not cause this behaviour. 5 control planes ~100 worker nodes ~1700 Pods
Can you provide the pprof without , so could compare the two?
Sure, the current pprof with set: ! !
cc
I believe this is Sounds like we may need to backport some of the dependency bumps
/assign
/sig instrumentation
/triage accepted (as it's now assigned to
/triage accepted
We need to apply the workaround in It should be simple, but needs to be backported to 1.27
all versions starting 1.27 right ?
Thanks for taking care of this so quickly
yes. All versions starting 1.27.
Actually, this only needs to be backported to v1.29.

At 1.28, we were using v0.35.0 of otelgrpc, which did not include metrics at the time.
Cherry-picks:
Change:
// HasSupport checks if the given gvk supports the query param configured on v func (v *QueryParamVerifier) HasSupport(gvk schema.GroupVersionKind) error { <ins> if (gvk == schema.GroupVersionKind{Version: "v1", Kind: "List"}) { return NewParamUnsupportedError(gvk, v.queryParam) } </ins> oapi, err := v.openAPIGetter.OpenAPISchema() if err != nil { return fmt.Errorf("failed to download openapi: %v", err)

Discussion:
kubectl apply performs validation before the apply. Non-CRD resources (e.g. pods / deployments) don't need CRD schema for validation, but if we use resource, kubectl calls . In my Kubernetes cluster, administrator doesn't allow users to list CRDs, so user cannot apply non-CRD resources (e.g. pods / deployments) with resource. doesn't happen because we're going to apply two Deployments. should not happen because we're going to apply two Deployments. No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig cli
/triage accepted /assign
/priority backlog
Change:
r.lastErrorTimeLock.Lock() defer r.lastErrorTimeLock.Unlock() d := time.Since(r.lastErrorTime) <del> if d < r.minPeriod { </del> <ins> if d < r.minPeriod && d >= 0 { // If the time moves backwards for any reason, do nothing // TODO: remove check "d >= 0" after go 1.8 is no longer supported </ins> time.Sleep(r.minPeriod - d) } r.lastErrorTime = time.Now()

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: in func OnError() of ErrorHandlers in apimachinery it is expected to go on sleep for some time if not meet the minPeriod. However, if time happens hops to the past in the process. would be a negative number, thus, it may sleep a lot longer than we expected. What you expected to happen: The period for sleep should be reseted if time hops
/sig api-machinery
adding a check on whether d is < 0 should fix it, no? if d < 0, simply don't sleep.
ooh, we have time travelling kubes now :)
so if d < 0, it's better to sleep r.minPeriod.
i think Go 1.9 should fix it, as reported and verified in the other issue