jiebi/CodeConvo huggingface dataset:
Change:
# This file creates a standard build environment for building cross # platform go binary for the architecture kubernetes cares about. <del> FROM golang:1.11.1 </del> <ins> FROM golang:1.11.2 </ins> ENV GOARM 7 ENV KUBE_DYNAMIC_CROSSPLATFORMS 

Discussion:
go 1.11.2 is out 11/2 and this bug tracks upgrade to the latest version. Is it something we should absolutely needed in the 1.13 timeframe? are there any that should absolutely take? how long does the associated image updates and push take? If we chose to upgrade in 1.13, we should do it before code slush targeted for Friday 11/6. /assign can you please clarify the above ques and and help evaluate timing of the upgrade. /cc /sig release /sig testing /priority important-soon /kind cleanup
/cc I’ve already got a branch cooking for this, but waiting for rules_go support first. I think said in Slack that this will happen this week.
Ahh so is the earliest expected timeframe when we can upgrade falls into Code slush period for 1.13 (post 11/9?) Depending on when it lands we might want to see if its safe to wait for 1.13.1. are you aware of any critical fixes that make this compelling for 1.13 timeframe?
The risk for patch golang point releases is typically low (the minor releases, like 1.10 -1.11, are higher risk). I don't see anything that's critical or of known impact, but at the same time, I see compiler fixes and go/types package fixes. They are more subtle and could present issues later. I'd suggest that if we can tolerate getting it in, even if we're in slush, we should.
Ack that :) Plz ping this bug as soon as we are ready to build and push the upgraded images. we'll will make a final call depending on the timeframe and CI signal going in. thanks!
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" <del> "github.com/GoogleCloudPlatform/kubernetes/pkg/kubelet/leaky" </del> "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" "github.com/GoogleCloudPlatform/kubernetes/pkg/registry/pod"

Discussion:
Kubelet now only reports ContainerStatus. PodStatus / PodCondition is observed at master side based on a set of ContainerStatus. There is no other way to get PodIP except net container for master side. This is very confusion to the end user, , , ... Now we are finalizing on v1beta3 API, including PodStatus & ContainerStatus. We can make net container completely invisible to the end users by finishing the following steps: 1) Expose network related errors at API level 2) Generate PodStaus directly from Kubelet
3) once PodStatus generated by kubelet, PodIP can be removed from ContainerStatus.
I think reporting PodStatus rather than just container status is most important. How hard is that?
Used to be hard since there are many dependencies when I first report Status back. Now it is totally feasible. I already started to write PRs for this. :-)
One more PR required to close this one.
Change:
createConfig.HostConfig.NetworkMode = dockercontainer.NetworkMode(networkMode) } else { // Todo: Refactor this call in future for calling methods directly in security_context.go <del> modifyHostNetworkOptionForContainer(false, podSandboxID, createConfig.HostConfig) </del> <ins> modifyHostOptionsForContainer(false, podSandboxID, createConfig.HostConfig) </ins> } return nil

Discussion:
https://k8s- https://k8s- cc: /kind bug /priority failing-test
/cc
Looking at the k8s-merge-robot in PR , it says: "pull-kubernetes-cross Skipped" (That's under "k8s-merge-robot merged commit into kubernetes:master 17 hours ago") Can someone tell why that test was skipped there? Wasn't the bot supposed to catch that breakage at that point instead? Just sent to fix this, someone please review. Thanks, Filipe
because the cross build is pretty expensive and takes a while, we only run it when we think a PR is likely to cause problems, based on the files it touches (regex at ). it's obviously not perfect - nothing in your PR immediately suggested there'd be a cross-build failure.
Ah ok I see thanks for the clarification!
Change:
oldPod := oldObj.(*api.Pod) newPod := newObj.(*api.Pod) if core.QuotaPod(oldPod) && !core.QuotaPod(newPod) { <del> options.ReplenishmentFunc(options.GroupKind, newPod.Namespace, newPod) </del> <ins> options.ReplenishmentFunc(options.GroupKind, newPod.Namespace, oldPod) </ins> } } }

Discussion:
master-informing: capz-windows-containerd-master capz-e2e.[It] Conformance Tests conformance-tests ! 2023-03-10 04:56:51 +0000 UTC No response /sig testing
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### Which jobs are failing? ### Since when has it been failing? /sig testing 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
/sig windows /triage accepted
no major change between passing test on 3/9 17:55 PST and failing test on 3/9 20:56 PST
containerd logs have error about failing to unpack azure-cloud-manager on both nodes:
kubelet logs confirm this:
looks to be related to bumping capz to 1.8 which uses the cloud-provider oot image: caused by upgrading to 1.8 capz in combination with using OOT
This looks to be affecting our release jobs as well:
looks like the image being built is linux only () and is being pulled by windows. When setting up the snapshot in containerd it is failing (as it is missing files required by windows)
For the passing test the image is multi-arch manifest, so the windows image pulls properly (azure-cloud-node-manager:)
There is a missing env in the see
Change:
framework.Failf("Error retrieving logs: %v", err) } <ins> if waitErr != nil { framework.Logf("Pod log:n%s", logOutput) framework.Failf("Pod did not stop running: %v", waitErr) } </ins> By("Verifying logs") verifyLogMessage(logOutput, "^Accepted client connection$") verifyLogMessage(logOutput, "^Received expected client data$")

Discussion:
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
So far I haven't found anything in the logs. The pfpod container starts, the e2e test receives all the data from it. At that time, the container should exit and the pod should be stopped. For some reason, either the container doesn't stop, or the kubelet doesn't see it stop. It's hard to tell which because the logs don't have enough information to make that determination.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
Might be the same issue as
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
Builds: kubernetes-e2e-gce-etcd3 kubernetes-e2e-gci-gce Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
Adding to assignee list b/c of ssh tunnel flakes (i.e.

this issue has multiple, different root causes)
Builds: ci-kubernetes-e2e-gce-etcd3 ci-kubernetes-e2e-gci-gce-etcd3 ci-kubernetes-e2e-gci-gce-proto kubernetes-e2e-gce-etcd3 kubernetes-e2e-gci-gce-kubenet kubernetes-e2e-gci-gce-proto kubernetes-e2e-gci-gce-release-1.4 kubernetes-e2e-gci-gke-prod-smoke Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
Closing this issue as the corresponding test has been removed from cc:
Change:
import ( "fmt" <ins> "io" </ins> "io/ioutil" "os" "path/filepath"

Discussion:
The reboot test may cause corrupted checkpoint left on the node. https://k8s- This prevents the sandbox from being stopped properly, so kubelet cannot create a new one. One option is to log and remove the corrupted checkpoint, while cleaning up the pod sandbox resources with best effort (i.e., may leak resources). Another option is to not clean up, and force a human being to intervene and remove the corrupt checkpoint manually. The proper solution perhaps is to scan the checkpoints at startup (or periodically) and repair/remove corrupt checkpoints. /cc related:
/cc
should this block ?
If we can scan the checkpoints at startup time, then repair the corrupted checkpoint, which means, we can recover the state from the runtime, why we introduce the checkpoint at the first place? :-) I am ok with your idea upon the corrupted checkpoints, removing the bad ones as the workaround. Anyway, Kubelet will fire an event of failedSync with the proper message, some manual intervene (the remedy system) can be fired based on the event to resolve the leak resource issue.
I think this shouldn't be the blocker for v1.6, but has an acceptable workaround to address this, and I would like to include that if no one disagreed with that approach.
Adding to milestone to track
Moving this back to 1.6. The checkpoint implementation use , which does not sync at all. No wonder the checkpoints would be corrupted in the reboot tests. I reproduced this issue with a simple go program + reboots on a VM. The problem went away once I forced a I will upload a PR to fix this. /cc
Change:
}, }, }, <ins> { storageClasses: []*storagev1.StorageClass{ makeDefaultStorageClass(classGold, &modeImmediate), makeStorageClass(classCopper, &modeImmediate), }, tests: []controllerTest{ { name:            "15-7 - pvc storage class is not changed if claim is not bound but already set annotation "volume.beta.kubernetes.io/storage-class"", initialVolumes:  novolumes, expectedVolumes: novolumes, initialClaims:   newClaimArray("claim15-7", "uid15-7", "1Gi", "", v1.ClaimPending, nil, v1.BetaStorageClassAnnotation), expectedClaims:  newClaimArray("claim15-7", "uid15-7", "1Gi", "", v1.ClaimPending, nil, v1.BetaStorageClassAnnotation), expectedEvents:  noevents, errors:          noerrors, test:            testSyncClaim, }, }, }, </ins> } for _, test := range tests { runSyncTests(t, test.tests, test.storageClasses, nil)

Discussion:
We observed that when deplying manifests to a cluster running 1.26.1-gke.200, the StorageClass and PVC get created successfully. However, the PVC is stuck in a Pending state and no PV is provisioned. The workaround is to add storageClassName to one of the pending PVCs on cluster, and it did go from Pending to properly provisioned a PV and reaching Bound state. We looked at the logs and found that according to the doc: , Is this annotation is fully deprecated in the new 1.26.1 release? If yes can we add this detail to documentation or release note? the PVC should not stuck in a Pending state and PV is provisioned in 1.26.1 a 1.26.1-gke.200 cluster in GKE via yaml The error comes form the code: and There are some hypotheses here: The annotation does not work on 1.26.1 any more, so a default storage class is being populated to the PVC. For some reason, the did not work, so the PVC was deployed with an empty StorageClass nil. Then the kube controller manager tried to update the PVC with the default StorageClass, which triggered the error: <details</details<detailsGKE </details<details</details<details</details<details</details<details</details
/sig storage
Annotation support seem to be still intact. Check the e2e test
From the point of view of the code, this annotation is still in use. I'll try to see if I can reproduce it.
It's a bug introduced in The feature is enabled in 1.26 by default.
/triage accepted
Change:
nopreserve  bool }{ "copy to pod no preserve user and permissions": { <del> expectedCmd: []string{"tar", "--no-same-permissions", "--no-same-owner", "-xf", "-", "-C", "."}, </del> <ins> expectedCmd: []string{"tar", "--no-same-permissions", "--no-same-owner", "-xmf", "-", "-C", "."}, </ins> nopreserve:  true, }, "copy to pod preserve user and permissions": { <del> expectedCmd: []string{"tar", "-xf", "-", "-C", "."}, </del> <ins> expectedCmd: []string{"tar", "-xmf", "-", "-C", "."}, </ins> nopreserve:  false, }, }

Discussion:
What happened: Copying a folder to a pod, e.g. postgresql-16-1-m7wjw results in the following error: time stamp 2019-02-12 12:17:06 is 0. s in the future What you expected to happen: Successful file upload to a given pod. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: perhaps this might come useful Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others:
/sig cli
Ran into this as well. That and it's annoying that cannot be used to create a directory structure when copying files into a container.
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 rotten
Change:
return newObj, nil } <ins> eqFn := equalities.DeepEqual if _, ok := newObj.(*unstructured.Unstructured); ok { // Use strict equality with unstructured eqFn = equalities.DeepEqualWithNilDifferentFromEmpty } </ins> // This condition ensures the managed fields are always compared first. If //	this check fails, the if statement will short circuit. If the check // 	succeeds the slow path is taken which compares entire objects. <del> if !equalities.DeepEqualWithNilDifferentFromEmpty(oldManagedFields, newManagedFields) { </del> <ins> if !eqFn(oldManagedFields, newManagedFields) { </ins> return newObj, nil } <del> if equalities.DeepEqualWithNilDifferentFromEmpty(newObj, oldObj) { </del> <ins> if eqFn(newObj, oldObj) { </ins> // Remove any changed timestamps, so that timestamp is not the only // change seen by etcd. //

Discussion:
Every time I server-side apply a with , the updates. Nothing about my manifest changes between applies; if I map to the empty map, the same manifest updates the . With client-side apply, the stays the same as long as my manifest remains constant, even if . I read in that Kubernetes should treat absent keys, empty values (in this case, an empty map), and values the same. I observe that leaving the key out and behave as expected, not modifying the and leaving the same, but empty map behaves as described above. If we cannot change this behavior, I'd at least like to understand the rationale behind it. I expected my object to stay the same between identical server-side applies, where the manifest file content was exactly the same, regardless of the value of . A different every apply indicates that the object was event type . I expect no events to fire on applying the same manifest. contains In actuality, any is fine. . Every successive repeat of steps 3-4 should show different values. Example of with : This is especially a problem when I server-side apply with code in my operator. My operator is built on and watches changes to the child objects it deploys. If I create a with , the operator constantly reconciles because every server-side apply of the manifest registers as a type event on the object, which triggers the watching operator to reconcile. N/A <details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted
Potentially similar case as
Change:
func (b *gcePersistentDiskMounter) SetUpAt(dir string, fsGroup *int64) error { // TODO: handle failed mounts here. notMnt, err := b.mounter.IsLikelyNotMountPoint(dir) <del> glog.V(4).Infof("PersistentDisk set up: %s %v %v", dir, !notMnt, err) </del> <ins> glog.V(4).Infof("PersistentDisk set up: %s %v %v, pd name %v readOnly %v", dir, !notMnt, err, b.pdName, b.readOnly) </ins> if err != nil && !os.IsNotExist(err) { return err }

Discussion:
Eg: Suspect it's because of:
If this hasn't been seen in 3 months, okay to close?
Yes we fixed it with
Change:
if !ignoreNotReady { return errors.New(errorBadPodsStates(badPods, desiredPods, ns, "RUNNING and READY", timeout)) } <del> Logf("Number of not-ready pods is allowed.") </del> <ins> Logf("Number of not-ready pods (%d) is below the allowed threshold (%d).", notReady, allowedNotReadyPods) </ins> } return nil }

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:
fmt.Fprintf(o.ErrOut, "Warning: resource '%s' is not namespace scoped in group '%s'n", o.Resource.Resource, o.Resource.Group) } } <ins> if !isKnownResourceVerb(o.Verb) { fmt.Fprintf(o.ErrOut, "Warning: verb '%s' is not a known verbn", o.Verb) } </ins> } if o.NoHeaders {

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: When using kubectl auth can-i <verb<resourcesthe "verb" isn't check and returns yes on any resource regardless of what the verb is. What you expected to happen: I expected the cli to register an error like when you don't have enough arguments. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): client version GitVersion: 1.19.2 server version: GitVersion: 1.19.0 Cloud provider or hardware configuration: Mac OS X OS (e.g: ): n/a Kernel (e.g. ): Darwin Install tools: brew Network plugin and version (if this is a network-related bug): n/a Others:
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
This is working as intended. The authorization layer can answer questions about arbitrary verbs, and the response to can-i mirrors the response you would get from a subjectaccessreview permission check. Getting a "yes" response to arbitrary verbs likely means you are a superuser and would be authorized for any operation.
Wouldn't a superuser only have access to the Kubernetes verbs that exist and not the arbitrary verbs that it is allowed to query that is defined here () This seems to go against the selfsubjectaccessreview which will return a set of actions that a user can perform. Arbitrary verbs seem like they shouldn't be allowed from that definition.
No, the cluster-admin superuser role allows verbs which allows any verb
Change:
List(filter string) ([]string, error) } <ins> // Zone represents the location of a particular machine type Zone struct { FailureDomain string Region        string } </ins> // Zones is an abstract, pluggable interface for zone enumeration. type Zones interface { <del> // GetZone returns the name of the current failure zone that the program is running in GetZone() (string, error) </del> <ins> // GetZone returns the Zone containing the current failure zone and locality region that the program is running in GetZone() (Zone, error) </ins> }

Discussion:
Comments that the PR bot adds solely to trigger email notification of a label change, should be immediately deleted by the bot after it adds them. I have no idea what team to assign this to... cc/
, David Oppenheimer wrote:
(Motivation, of course, is to avoid having PR threads that are 90% bot comments...)
should really be an issue over in that's where (some of) the bots live. Lets make a list of which comments we want deleted immediately. [x] Label size. [x] Needs rebase. [x] test this stale CI [x] test this pending CI [x] PR changed after LGTM, removing LGTM. [x] Comment about blocking based on the paths touched (old docs) [x] unapproved cherrypick comment [x] cherrypicks must set a milestone [x] ok to test from bot I don't want to make it all comments. There are way too many times people have asked me "Why did the bot add 'do-not-merge'?" and I can just link them the comment 2 lines above which tells exactly why....
"Test this" with an issue is also useful, isn't it? On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
OK to test Add to whitelist On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
I was envisioning deleting the by the bot. (every 48 hours after LGTM, when retesting right before merge) not those by users (with an issue) After LGTM the bot will add , that one I can remove. The request to comes from the jenkins bot. And in that I am clueless...
any interest in a review (I'm trying to not just self merge all my own bot changes). This deleted hundreds and hundreds of comments.
Looks like reviewed it since your last message:

The contains instructions for downloading kubectl. The doesn't contain these instructions but it should if it's now the recommended way of running Kubernetes locally.
+1 Just ran into this.
cc
By the way, we encourage anyone to propose improvements/fixes to docs. You can do so pretty easily by clicking the pencil icon in the top right corner of every page of
kubectl download instructions to the guide in