jiebi/CodeConvo huggingface dataset:
Change:
Items []Foo `json:"items"` } <del> var _ = Describe("ThirdParty resources", func() { </del> <ins> // This test is marked flaky pending namespace controller observing dynamic creation of new third party types. var _ = Describe("ThirdParty resources [Flaky] [Disruptive]", func() { </ins> f := framework.NewDefaultFramework("thirdparty")

Discussion:
ThirdPartyResources (TPR) E2E test creates a custom resource type, and creates an instance of that type in a namespace. The namespace is purged, but the namespace controller DOES NOT observe the dynamic mutation of the type hierarchy. As a result, the instances of that type are never purged, and we could potentially leak resources. In prior discussions of we agreed that users of TPR would have to kick the namespace controller in the interim in order for it to observe the creation of the new TPR type and have it take part in namespace lifecycle. If TPR is a priority, we should address the namespace controller issue in kube 1.5, and eliminate the [Flaky] flag from the TPR E2E. The updates in the e2e framework that intropsect the server dynamically to verify all resources are deleted are getting tripped up by the presence of this test and impacting all others. Here is an example: https://k8s- /cc
+1 to [Flaky] - this is really causing a ton of flakes
Also note that this doesn't just affect the TPR e2e suite - the existence of the TPR can cause any other e2e suite to fail.
/cc

https://k8s- Failed: ThirdParty resources Simple Third Party creating/deleting thirdparty objects works [Conformance] {Kubernetes e2e suite}
cc
Seems like the namespace creation/deletion process is flaky. IIRC there have been some recent PRs touching this area, is that right?
We recently code to try to expose the real underlying error for why the ns deletion fails. This is hopefully now showing it.
The issue is with TPR not integrated properly with the namespace controller. Creation of a new type requires a restart of the controller-manager given current state of the code. The test must be marked flaky until the state of the art is improved (which is not happening in 1.4).
Change:
# Execute after running tests to perform any required clean-up function test-teardown { <del> echo "Vagrant ignores tear-down" 1>&2 </del> <ins> kube-down </ins> } # Set the {user} and {password} environment values required to interact with provider

Discussion:
We should call kube-down in e2e when running teardown. Currently we just . In doing so we also need to ensure that minion-2 is torn down. When calling cluster/kube- manually master and minion-1 are torn down correctly while minion-2 is missed. /cc
I think sorting this out should resolve any issues from and
Change:
return true, nil, nil } <del> // haveOverlap searches two arrays and returns true if they have at least one common element; returns false otherwise. func haveOverlap(a1, a2 []string) bool { if len(a1) > len(a2) { a1, a2 = a2, a1 } m := map[string]bool{} for _, val := range a1 { m[val] = true } for _, val := range a2 { if _, ok := m[val]; ok { return true } } return false } </del> // GeneralPredicates checks a group of predicates that the kubelet cares about. // DEPRECATED: this exist only because kubelet uses it. We should change kubelet to execute the individual predicates it requires. func GeneralPredicates(pod *v1.Pod, meta Metadata, nodeInfo *schedulernodeinfo.NodeInfo) (bool, []PredicateFailureReason, error) {

Discussion:
/sig scheduling /priority important-soon See as an example. Part of /assign
GitHub didn't allow me to assign the following users: angao. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /sig scheduling /priority important-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
thx, I will do it soon.
Change:
gateEnabled: false, want:        nil, }, <ins> "enabled with valid spec but nil APIGroup": { spec:        validSpecNilAPIGroup, gateEnabled: true, want:        validSpecNilAPIGroup.DataSource, }, "disabled with valid spec but nil APIGroup": { spec:        validSpecNilAPIGroup, gateEnabled: false, want:        nil, }, </ins> } for testName, test := range tests {

Discussion:
What happened: While implementing the new VolumePVCDataSource feature I discovered that even though the we don't use APIGroup (the appropriate setting is ) if the APIGroup is omitted it results in a nil pointer exception on the API server. What you expected to happen: APIGroup should be able to be omitted from the spec How to reproduce it (as minimally and precisely as possible): Create a spec to create a clone of a PVC with out the APIGroup parameter in the DataSource spec: The result will be an nil pointer exception during the verification of the datasource field. Adding the APIGroup entry will address this as a work-around: Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.0-alpha.1.+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2019-06-12T22:12:02Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Install tools: local-up-
I have a simple fix, will post PR in a moment
/sig storage
/priority critical-urgent /milestone v1.15
Change:
go_test( name = "go_default_test", <del> srcs = ["convert_test.go"], </del> <ins> srcs = [ "convert_test.go", "import_known_versions_test.go", ], </ins> data = [ "//test/fixtures", ], embed = [":go_default_library"], deps = [ <ins> "//pkg/api/legacyscheme:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", </ins> "//staging/src/k8s.io/cli-runtime/pkg/genericclioptions:go_default_library", <ins> "//staging/src/k8s.io/client-go/kubernetes/scheme:go_default_library", </ins> "//staging/src/k8s.io/client-go/rest/fake:go_default_library", "//staging/src/k8s.io/kubectl/pkg/cmd/testing:go_default_library", ],

Discussion:
What happened: Tried to convert a v1beta1 Ingress object to v1, and received the following error: What you expected to happen: The conversion to work. How to reproduce it (as minimally and precisely as possible): Then run: /sig cli /assign
Can i work on this issue?
/assign
/triage accepted
Change:
petMounts := []api.VolumeMount{{Name: "datadir", MountPath: "/data/"}} podMounts := []api.VolumeMount{{Name: "home", MountPath: "/home"}} ps := newStatefulSet(psName, ns, headlessSvcName, 3, petMounts, podMounts, labels) <ins> setInitializedAnnotation(ps, "false") </ins> _, err := c.Apps().StatefulSets(ns).Create(ps) Expect(err).NotTo(HaveOccurred())

Discussion:
What happened: What you expected to happen: The statefulset should have scaled down to 0. Instead, even after 10 minutes: How to reproduce it (as minimally and precisely as possible): Run the e2e test on a gce cluster running the latest and greatest kubernetes. cc
if the petset has replicas=0 it's not going to do anything
When I a running petset, and set its scale to 0, that seems to work and delete the pets, and we should have a functioning scaler. Am I misunderstanding something? I'm using the same teardown process for the e2e test I linked in the issue as the other tests (), but it times out sometimes after network partition.
yeah is scale in the petset controller noticing deletion timestamp? because the test code you showed doesn't care
As I mentioned yesterday, it isn't even issuing a delete request even after 10 minutes, because the pods continue to be "running". I'll check the controller manager logs today. I suspect it might be the backoff in the rate limited work-queue.
Hmm, the AGE fields on your pets don't make sense if it isn't even issuing a delete?
In the output I pasted above, at the 7 minute mark, it created the new replacement pet-0, after the network partition was healed. Then tried to scale down the StatefulSet and waited 10 minutes for the pods to disappear.
I see a bunch of different failures modes on the bug: 3 08:58:44.475: Failed waiting for pods to enter running: timed out waiting for the condition Failed to scale statefulset to 0 in 10m0s. Remaining pods: [] 3 08:11:30.728: Unexpected error: <nilBasically 3 translates to We should clarify. 1 and 2 both have events like guessing the node controlelr shouldn't be setting timestamp?
Looking into the case 2: The controller manager log goes: So I guess even deletions are being blocked by the health/readiness.
Both issues appear to be due to the testsuite and the way we use the "initialized" annotation in tests. I'll send a PR to fix these shortly. Thanks
Change:
- file: /etc/init.d/kubelet {% endif %} - file: /var/lib/kubelet/kubernetes_auth <ins> {% if pillar.get('enable_node_monitoring', '').lower() == 'true' %} - file: /etc/kubernetes/manifests/cadvisor.manifest {% endif %} </ins>

Discussion:
On latest pull, the Vagrant kube- scripts completes successfully, but the Salt setup in the minion keeps going forever. End result is a cluster that is not useable. Looking at '/var/log/salt/minion' on the minion box, see lots of entries like: 2015-03-04 20:09:11,952 [ ][INFO ] Starting a new job with PID 2015-03-04 20:09:11,954 [ ][INFO ] Returning information for job: 2015-03-04 20:09:12,027 [ ][DEBUG ] Decrypting the current master AES key 2015-03-04 20:09:12,028 [ ][DEBUG ] Loaded minion key: 2015-03-04 20:09:12,217 [ ][INFO ] User vagrant Executing command with jid 2015-03-04 20:09:12,217 [ ][DEBUG ] Command details {'tgt_type': 'glob', 'jid': '', 'tgt': '*', 'ret': '', 'user': 'vagrant', 'arg': [], 'fun': ''} No other help looking at the master's salt log. This is Vagrant 1.7.2, with VirtualBox 4.3.20 on Mac OSX (Yosemite).
Is this repeatable for you if kube-down and kube-up?
Yes, this is reproducible on my laptop. But, I was able to get it up by doing a kube-push after the failed kube-up. , Eric Tune wrote:
Self assigning and will try to reproduce. Sent from my iPhone
I was able to reproduce. It appears that the Kubelet fails to start properly on first start:
The push basically caused the Kubelet to restart, and then it does work. Without the push, systemd would have eventually restarted the Kubelet. We need more investigation as to what was causing the Kubelet to fail on initial startup.
Change:
etcd_over_ssl: 'false' EOF fi <ins> if [ -n "${ETCD_QUORUM_READ:-}" ]; then cat <<EOF >>/srv/salt-overlay/pillar/cluster-params.sls etcd_quorum_read: '$(echo "${ETCD_QUORUM_READ}" | sed -e "s/'/''/g")' EOF fi </ins> # Configuration changes for test clusters if [ -n "${APISERVER_TEST_ARGS:-}" ]; then cat <<EOF >>/srv/salt-overlay/pillar/cluster-params.sls

Discussion:
Slack user "nalin" reported an issue Looking at the code this makes sense. Will fix.
For anyone following along, the fix for this bug unfortunately didn't get cherrypicked because of a process issue, and is broken until 1.5.2. cc
I just the new lines from As a temperatur fix ONLY. If anyone like me dont want to wait. Worked like at charm for AWS cluster setup. :)
A quick note, just as confirmation: the above temporary fix does resolve the issue for AWS - even though it's a change to a GCE-related file (cluster/gce/configure-). It seems that the GCE files are used for certain aws functions.
In based AWS deployment, the script is shared between AWS and GCE.
Also, this fix was cherry-picked into the branch a while ago, so instead of manually adding the lines, you can also just checkout the branch and run from there.
Change:
match: registry.k8s.io/build-image/debian-base:[a-zA-Z]+-v((([0-9]+).([0-9]+).([0-9]+)(?:-([0-9a-zA-Z-]+(?:.[0-9a-zA-Z-]+)*))?)(?:+([0-9a-zA-Z-]+(?:.[0-9a-zA-Z-]+)*))?) - name: "registry.k8s.io/distroless-iptables: dependents" <del> version: v0.6.1 </del> <ins> version: v0.5.6 </ins> refPaths: - path: build/common.sh match: __default_distroless_iptables_version=

Discussion:
sgtm, add an issue labeled as release-blocking and in the milestone to either promote to 1.23.0 or revert this to 1.22.x before our 1.31 release Originally posted by in Kubernetes is being built and tested with go1.23rc2 at HEAD () to let it bake in the CI and help iron out issues, if any, with this version of Go. However, for the 1.31 release, the version of Go should be a non-rc, released version. The release timeline of go1.23.0 is ~same as the release timeline of K8s 1.31.0 (see ). If go1.23.0 is not out by then, we should revert to go1.22.x before cutting K8s 1.31.0. /sig release architecture /area code-organization /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted /cc
/milestone v1.31
cc
xposting relevant slack thread:
Also unlike in the past, missing shipping 1.23.0 in 1.31.0 is not a big deal, we have much more room to switch to 1.23.0 in a patch release after all the compat changes with the go team. So we should not fear reverting if the timelines don't line up.
(though go1.23 adds the thing that makes it workable to default to old go version compat settings, so we'll have to eke out another 5 months on 1.21/1.22 for until we can adopt 1.23 on release branches in ~Jan if we miss 1.31, but that's how it looks like it will have to happen)
Change:
} } <del> if err := checkPermissions(); err != nil { klog.Error(err) } </del> utilruntime.ReallyCrash = s.ReallyCrashForTesting // TODO(vmarmol): Do this through container config.

Discussion:
What happened: follow on to Need to comment and avoid checking UID on windows. requires some research into what we should be checking so that we can add appropriate TODO. What you expected to happen: Lets also check this at the call site, Anything else we need to know?: Environment: Kubernetes version (use ): master OS (e.g: ): windows
/assign
/assign
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue 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
Hi are you working on this issue already? If not I'd like to tackle this issue :)
Hi yeah I am already working on this :)
Started branch for this here
thanks
Hey guys is there anything I can do here?
If you want to test perks patch that would be great ?
That sounds great Where do I get started?
Hey ! is there anything I can help with? and how?
I dont think there is anything left to do anything more that you think we need to do to get this merged?
Tested this with containerd as well, I think its good to test
/triage accepted
Change:
e2essh "k8s.io/kubernetes/test/e2e/framework/ssh" ) <del> // TestContext should be used by all tests to access common context data. var TestContext framework.TestContextType </del> // New local storage types to support local storage capacity isolation var localStorageCapacityIsolation featuregate.Feature = "LocalStorageCapacityIsolation"

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: Flexvolume e2e tests are skipped in https://k8s-, so as far as I can tell we don't have Flexvolume test coverage. They are skipped because they require SSH access to drop the Flexvolume plugin onto the host, but these test clusters do not have SSH access. We should change all Flexvolume tests to use the DaemonSet installation mechanism instead which does not require SSH access. See and Flexvolume tests I'm aware of are below, but there could be more: Looking for help with this bug! /sig storage /priority important-soon /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : <!-- 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: Flexvolume e2e tests are skipped in https://k8s-, so as far as I can tell we don't have Flexvolume test coverage. /priority important-soon /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
Hi, Can I work on this issue? I think i know how to handle it.
are you still working on this? I'm interested in helping out as well.
/assign
Change:
linux/s390x linux/ppc64le darwin/amd64 <ins> darwin/arm64 </ins> windows/amd64 windows/386 )

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : When trying to build kubectl from tip () on a M1 Macbook: Why is this needed: M1 MacBooks are a new major client platform that many developers will use. brew listed kubectl (kubernetes-cli) is one of the major packages still not supported on M1 () Since it's supported by go, it's only required to add it to the supported client list Locally I managed to add support using the following patch:
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 architecture
/sig release
Any updates on this? cheers
you can watch the PR:
it works, nice!!!
Done!!!
Change:
} cgroupConfig.Resources.SkipDevices = true <ins> // if the hugetlb controller is missing supportedControllers := getSupportedUnifiedControllers() if !supportedControllers.Has("hugetlb") { cgroupConfig.Resources.HugetlbLimit = nil // the cgroup is not present, but its not required so skip it klog.V(6).Infof("Optional subsystem not supported: hugetlb") } </ins> manager, err := cgroupfs2.NewManager(cgroupConfig, cgroupConfig.Path, false) if err != nil { return fmt.Errorf("failed to create cgroup v2 manager: %v", err)

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: kubelet doesn't start up on a cgroup2 host without hugetlb controller What you expected to happen: Should work without hugetlb controller How to reproduce it (as minimally and precisely as possible): Boot Ubuntu 20.04 host with . Make sure cgroup v2 controllers are enabled but hugetlb is not: Install Moby from its master branch (Docker 20.0X). Binaries are available at Install kind from its master branch (kubernetes-sigs/kind Run with kubernetes/kubernetes Run Run Environment
cc
/sig sig-node
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig sig-node </details
/sig node
/area kubelet
looks like you already saw since you filed :)
That’s for containerd, not for kubelet :)
right :)
we can relax the hugetlb requirement, since it is also optional on cgroup v1. could you please try if the following patch is enough to fix the issue on your environment?
LOL this again :-) guess this isn't just glinux with hugetlb issues :upsidedownface:
IKR!!!
Perfect, could you open a PR? Now kind works on cgroup v2!
opened a PR here:
Change:
t.Errorf("[%v]Unexpected test result. Expected delete %v, got %v", description, expectDelete, podDeleted) } } <ins> // TestPodDeletionEvent Verify that the output events are as expected func TestPodDeletionEvent(t *testing.T) { f := func(path cmp.Path) bool { switch path.String() { // These fields change at runtime, so ignore it case "LastTimestamp", "FirstTimestamp", "ObjectMeta.Name": return true } return false } t.Run("emitPodDeletionEvent", func(t *testing.T) { controller := &NoExecuteTaintManager{} recorder := testutil.NewFakeRecorder() controller.recorder = recorder controller.emitPodDeletionEvent(types.NamespacedName{ Name:      "test", Namespace: "test", }) want := []*v1.Event{ { ObjectMeta: metav1.ObjectMeta{ Namespace: "test", }, InvolvedObject: v1.ObjectReference{ Kind:       "Pod", APIVersion: "v1", Namespace:  "test", Name:       "test", }, Reason:  "TaintManagerEviction", Type:    "Normal", Count:   1, Message: "Marking for deletion Pod test/test", Source:  v1.EventSource{Component: "nodeControllerTest"}, }, } if diff := cmp.Diff(want, recorder.Events, cmp.FilterPath(f, cmp.Ignore())); len(diff) > 0 { t.Errorf("emitPodDeletionEvent() returned data (-want,+got):n%s", diff) } }) t.Run("emitCancelPodDeletionEvent", func(t *testing.T) { controller := &NoExecuteTaintManager{} recorder := testutil.NewFakeRecorder() controller.recorder = recorder controller.emitCancelPodDeletionEvent(types.NamespacedName{ Name:      "test", Namespace: "test", }) want := []*v1.Event{ { ObjectMeta: metav1.ObjectMeta{ Namespace: "test", }, InvolvedObject: v1.ObjectReference{ Kind:       "Pod", APIVersion: "v1", Namespace:  "test", Name:       "test", }, Reason:  "TaintManagerEviction", Type:    "Normal", Count:   1, Message: "Cancelling deletion of Pod test/test", Source:  v1.EventSource{Component: "nodeControllerTest"}, }, } if diff := cmp.Diff(want, recorder.Events, cmp.FilterPath(f, cmp.Ignore())); len(diff) > 0 { t.Errorf("emitPodDeletionEvent() returned data (-want,+got):n%s", diff) } }) } </ins>

Discussion:
Events from node taint manager doesn't report involved object apiVersion: ! apiVersion is reported as other events. For example: ! a pod on node A (not master) off node A is reported, but without apiVersion in involvedObject. The apiVersion is not reported in The issue is still not fixed in master: ! <details</details<detailsIrrelevant </details<details</details<details</details<details</details<details</details
/sig node /sig apps
/assign In the latest version, the issue is confirmed
one suggestion you should wait for the corresponding SIG to triage the issue and accept it before sending PRs, the chances of your PR getting reviewed and approver are much higher
You are right sorry about that. It won’t happen again.
no no worries, it was a suggestion, is not that you did something wrong, but it is possible that your PR doesn't get reviews and you get frustrated
/remove-sig node please re-add if this is node-related issue
I think it is a node related issue. The root cause in taint manager.
/sig node
/assign /triage accepted
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/types" </ins> "github.com/golang/glog" )

Discussion:
now shows NodePhase, NodeCondition, etc. information from NodeStatus. It should also show related events like what we did for pods.