jiebi/CodeConvo huggingface dataset:
Change:
-A KUBE-SERVICES -m comment --comment "kubernetes service nodeports; NOTE: this must be the last rule in this chain" -m addrtype --dst-type LOCAL -j KUBE-NODEPORTS COMMIT ` <ins> assert.Equal(t, []*netutils.LocalPort{ { Description: "nodePort for ns1/svc1:p80", IP:          "", IPFamily:    netutils.IPv4, Port:        svcNodePort, Protocol:    netutils.TCP, }, }, fp.portMapper.(*fakePortOpener).openPorts) </ins> assertIPTablesRulesEqual(t, expected, fp.iptablesData.String()) }

Discussion:
I've been following the official docs for kubeadm and how to set up a new cluster. The cluster is up and running but I noticed warning events when creating node port services: However, the node port does work (I see the output when accessing node ip:nodeport). Might it be related to something else than Kubernetes? There is no such warning event. Set up a fresh cluster with kubeadm and then create a service of nodeport type. No response <details</details<detailsHetzner cloud </details<details</details<detailscloud-init </details<detailscontainerd </details<detailscni=cilium csi=hetzner </details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
check with netstat or ss if there is a process listening on that port
no, I specified exact random port e.g. and checked it before with ss - it was not being used. Then I created the service, the warning occured, and after that the port was taken:
kube-proxy binds the NodePort to warn users that they may be shadowing a process, but it logs the errors if it can not bind the port
I met the same error and I confirmed the node port was not used by any other process. After looking into the code, I think this is a bug in kube-proxy that it would try to open a node port twice with same (empty) IP and port when is empty. contains and in below code.: I have created to fix it.
Awesome find. Did you figure out a work around?

I am encountering this issue with this version of the image:
The error looked scaring but the nodePort should be working, as it was just caused by a duplicate port opening attempt. v1.23.5 and later releases have the fix.
Change:
pod.Spec.HostNetwork = true _, err := cs.CoreV1().Pods(ns).Create(pod) framework.ExpectNoError(err) <del> framework.ExpectNoError(f.WaitForPodRunning(podName)) </del> <ins> framework.ExpectNoError(f.WaitForPodReady(podName)) </ins> framework.Logf("Netexec pod %q in namespace %q running", podName, ns) defer func() {

Discussion:
Per PR the test fails to error properly. One line of particular interest from that PR: If you wonder why it does not fail on docker, that's because the test does not report the error correctly but fails the same way. This issue is intended to track the discussion and resolution of making this test error properly so that it is useful to CI Signal /sig networking /cc
The label(s) cannot be appled. These labels are supported: <detailsIn response to : Per PR the test fails to error properly. One line of particular interest from that PR: If you wonder why it does not fail on docker, that's because the test does not report the error correctly but fails the same way. ` /cc </details
I'm following up on this in
/sig network
Change:
# Heapster <del> Heapster enables monitoring of Kubernetes Clusters using [cAdvisor](https://github.com/google/cadvisor). Detailed information about heapster can be found [here](https://github.com/GoogleCloudPlatform/heapster). </del> <ins> Heapster enables monitoring of Kubernetes Clusters using [cAdvisor](https://github.com/google/cadvisor). The kubelet will communicate with an instance of cAdvisor running on localhost and proxy container stats to Heapster. Kubelet will attempt to connect to cAdvisor on port 4194 by default but this port can be configured with kubelet's `-cadvisor_port` run flag. Detailed information about heapster can be found [here](https://github.com/GoogleCloudPlatform/heapster). </ins>

Discussion:
Currently, kubelet uses a for communicating with cAdvisor. , were having an issue because we didn't realize making port available was required for kubernetes.
I prefer not do this since we plan to make 4194 publically reserved port for cAdvisor. Also cAdvisor is the default deamon running on every node of a kubernetes cluster. The issue you encountered sounds like a bad document issue we had for cAdvisor. We should fix the document instead of allow the port being configurable.
can you expound on 'bad document' issue?
Change:
# Stop docker before making these updates systemctl stop docker <ins> # Install openvswitch yum install -y openvswitch systemctl enable openvswitch systemctl start openvswitch </ins> # create new docker bridge ip link set dev ${DOCKER_BRIDGE} down || true brctl delbr ${DOCKER_BRIDGE} || true

Discussion:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?
Change:
"networking.go", "node_lease.go", "pods.go", <ins> "podtemplates.go", </ins> "privileged.go", "projected_combined.go", "projected_configmap.go",

Discussion:
This issue proposes the writing of a new test for the API endponts , , , and 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 these results from APIsnoop, we are lacking in test coverage and conformant tests for PodTemplate. We chose these three following endpoints for this mock test: - - Outline: PodTemplates, Expect no PodTemplates a PodTemplate (1), Expect no error PodTemplate (1), Ensure the same as how it was created PodTemplate (1) with label a=1, Expect no error PodTemplate (1), Expect label in returned data to be present PodTemplates by label a=1, Expect one PodTemplate PodTemplate (1) Expect no error PodTemplates, Expect no PodTemplates Fetch dependencies: This mock test is using client-go's standard functions to talk to the PodTemplate part of the API. If a test with these calls gets merged in, conformance will go up by 3 endpoints. /sig architecture /area conformance
We decided not to deprecate. We can link to that, but otherwise this is OK to write / promote.
ref: for the decision not to deprecate
/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:
k8sruntime "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/client-go/kubernetes/scheme" <ins> restclient "k8s.io/client-go/rest" </ins> ref "k8s.io/client-go/tools/reference" )

Discussion:
What happened: kube-scheduler panics when client-go tries to finish the existing event series, see: What you expected to happen: kube-scheduler should not panic How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority critical-urgent /sig scheduling
Change:
options = metav1.NewDeleteOptions(int64(gracePeriod)) } options.OrphanDependents = &orphan <del> return deleteResource(info, out, shortOutput, options) </del> <ins> return deleteResource(info, out, shortOutput, options, gracePeriod) </ins> }) if err != nil { return err

Discussion:
IMO it's surprising that does not force delete a resource. only takes effect when . The description of reads this: We should make it more clear what does and even print warnings when is specified without .
Changing the meaning of force to actually break cluster consistency be default could lead to data loss, which is why we haven’t changed it so far. agree we should print more info and clarfiy
Change:
}, { APIGroups: []string{""}, <del> Resources: []string{"persistentvolumesclaims"}, </del> <ins> Resources: []string{"persistentvolumeclaims"}, </ins> Verbs:     []string{"get", "list", "watch", "update"}, }, {

Discussion:
Current CSI E2E test has some issues which prevent it to run successfully the a local cluster. /sig storage /kind bug /assign
Change:
c.supportsSELinux, err = c.kubeVolHost.GetHostUtil().GetSELinuxSupport(dir) if err != nil { <del> klog.V(2).Info(log("error checking for SELinux support: %s", err)) </del> <ins> // The volume is mounted. Return UncertainProgressError, so kubelet will unmount it when user deletes the pod. return volumetypes.NewUncertainProgressError(fmt.Sprintf("error checking for SELinux support: %s", err)) </ins> } if !driverSupportsCSIVolumeMountGroup && c.supportsFSGroup(fsType, mounterArgs.FsGroup, c.fsGroupPolicy) {

Discussion:
On a busy system, kubelet failed to tell the container runtime that a pod's CSI volume supports SELinux and should be relabeled with pod's SELinux label. The pod then can't access the volume. Kubelet correctly detects that the CSI volume supports SELinux and tells the container runtime to relabel it. Unknown. Get a busy system and try hard? CSI volume plugin tried to detect that the volume supports SELinux during SetupAt. This check failed: Current CSI volume plugin code silently consumes the error and assumes that the volume does not support SELinux at all: Therefore, the volume is marked as mounted and given to the container runtime without the right SELinux options and the runtime does not relabel volume. <details22.0 </details<detailsNone </details<details</details<details</details<detailsCRI-O, but I think it's not really relevant. </details<details</details
/sig storage /triage accepted
We've updated kubelet in our clusters to v1.20.13 (which contains the cherry picked fix), but still observe the issue
Change:
# Entry provided via env var to simplify invocation. if [[ -n ${E2E_USE_GO_RUNNER:-} ]]; then set -x <del> /gorunner exit $? </del> <ins> /gorunner && ret=0 || ret=$? exit ${ret} </ins> fi # We get the TERM from kubernetes and handle it gracefully

Discussion:
Same as an issue that occurred for v1.14.0: the failing test causes ginkgo to exit non-zero which causes the script to abort without running the routine. A recent PR to this script fixed a race but we didn't realize that now that the command was running in the foreground (and not the background) that the non-zero status would impact that script. Currently, Sonobuoy can get around this by just using the Golang based runner via . The Go-runner does not seem to have a similar vulnerability. This is going to be the default for Sonobuoy runs starting in Sonobuoy v0.16.0 if the PR gets merged. Honestly, I think that we may want to consider just removing the bash script all-together for v1.17.0 if the go runner works well for this entire cycle. See the original reporting of the issue and diagnosis here: /sig testing /area conformance /priority important-soon
/assign The PR in question that re-emerged this problem: FWIW Sonobuoy is adding an integration suite that will be able to test this going forward (soon). I think we need to fix the script (and get it cherrypicked into v1.16.x branches) I think that if the go runner proves stable over v1.16 then we default to it going forward We consider removing entirely if we think we can do that without impacting other workflows. Maybe that wont be possible due to other workflows though. cc
is probably never called due to , it can probably be fixed by adding a or before line 70.
Yes that is exactly why it is but in the past when I recommended removing/modifying the errexit code I've gotten pushback from a googler just due to convention: see Just will add something like to the lines that need this
Change:
"STANDARD_E8S_V3":        16, "STANDARD_E8_V3":         16, "STANDARD_E96AS_V4":      32, <ins> "STANDARD_E96A_V4":       32, </ins> "STANDARD_F1":            4, "STANDARD_F16":           64, "STANDARD_F16S":          64,

Discussion:
<!-- Please only use this template for submitting enhancement requests -- What would you like to be : related to Why is this needed: /assign /sig azure
here is the way about how to get MaxDataDiskCount: and then build kubelet, copy kubelet to agent node and then get MaxDataDiskCount data: There are 207 VM sizes totally.
Update: this command could get VM size list easily:
Change:
nodeName := pod.Spec.NodeName gomega.Expect(nodeName).NotTo(gomega.BeEmpty(), "pod.Spec.NodeName must not be empty") <del> ginkgo.By(fmt.Sprintf("[init] waiting until the node=%s is not using the volume=%s", nodeName, pv.Name)) </del> <ins> // Snapshot tests are only executed for CSI drivers. When CSI drivers // are attached to the node they use VolumeHandle instead of the pv.Name. volumeName := pv.Spec.PersistentVolumeSource.CSI.VolumeHandle ginkgo.By(fmt.Sprintf("[init] waiting until the node=%s is not using the volume=%s", nodeName, volumeName)) </ins> success := storageutils.WaitUntil(framework.Poll, f.Timeouts.PVDelete, func() bool { node, err := cs.CoreV1().Nodes().Get(context.TODO(), nodeName, metav1.GetOptions{}) framework.ExpectNoError(err) volumesInUse := node.Status.VolumesInUse framework.Logf("current volumes in use: %+v", volumesInUse) for i := 0; i < len(volumesInUse); i++ { <del> if strings.HasSuffix(string(volumesInUse[i]), pv.Name) { </del> <ins> if strings.HasSuffix(string(volumesInUse[i]), volumeName) { </ins> return false } } return true }) framework.ExpectEqual(success, true) } cleanup := func() {

Discussion:
The volume snapshot controller tests can result in an empty VolumeSnapshot being taken if NodeUnstageVolume occurs after the VolumeSnapshot is taken. Previously there was a change made in Windows to ensure that NodeUnstageVolume finishes before continuing with the test; however, this needs to also to be included in other distros as well. NodeUnpublish, which removes the bind mount, does not force the caches to flush. Tests - The CI jobs should pass when running with a non-hostpath driver. I'm uncertain on why we've seen an increase in these failures, but running the following tests with a non-hostpath driver appear to flake regularly: [Testpattern: Pre-provisioned Snapshot (retain policy)] snapshottable[Feature:VolumeSnapshotDataSource] volume snapshot controller should check snapshot fields, check restore correctly works after modifying source data, check deletion [Testpattern: Pre-provisioned Snapshot (delete policy)] snapshottable[Feature:VolumeSnapshotDataSource] volume snapshot controller should check snapshot fields, check restore correctly works after modifying source data, check deletion [Testpattern: Dynamic Snapshot (retain policy)] snapshottable[Feature:VolumeSnapshotDataSource] volume snapshot controller should check snapshot fields, check restore correctly works after modifying source data, check deletion [Testpattern: Dynamic Snapshot (delete policy)] snapshottable[Feature:VolumeSnapshotDataSource] volume snapshot controller should check snapshot fields, check restore correctly works after modifying source data, check deletion In these tests we've seen the following with the AWS EBS CSI Driver. Driver logs on the node: In the driver logs (in the controller pod) I can see:
/sig storage
/triage accepted /priority important-soon all snapshot tests with real CSI drivers are quite flaky, I saw it at least in AWS, Azure and GCE in a downstream CI job
Change:
} // TODO use generalized labels once they are implemented (#341) <del> b := resource.NewBuilder(mapper, typer, factory.ClientMapperForCommand(cmd)). </del> <ins> b := resource.NewBuilder(mapper, typer, factory.ClientMapperForCommand()). </ins> NamespaceParam(cmdNamespace).DefaultNamespace(). SelectorParam("kubernetes.io/cluster-service=true"). ResourceTypeOrNameArgs(false, []string{"services"}...).

Discussion:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR
Change:
} } } <ins> for i := range podSpec.Containers { DropDisabledVolumeMountsAlphaFields(podSpec.Containers[i].VolumeMounts) } for i := range podSpec.InitContainers { DropDisabledVolumeMountsAlphaFields(podSpec.InitContainers[i].VolumeMounts) } } // DropDisabledVolumeMountsAlphaFields removes disabled fields from []VolumeMount. // This should be called from PrepareForCreate/PrepareForUpdate for all resources containing a VolumeMount func DropDisabledVolumeMountsAlphaFields(volumeMounts []api.VolumeMount) { if !utilfeature.DefaultFeatureGate.Enabled(features.MountPropagation) { for i := range volumeMounts { volumeMounts[i].MountPropagation = nil } } </ins> }

Discussion:
says "Before persisting the object to storage, clear disabled alpha fields". There is that actually implements it but there are some discussions about it. This issues is a reminder that introduced by needs to be cleared too when the discussion in settles down. /assign
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
kind/cleanup priority/important-soon
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/api-machinery: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
Change:
} } <del> func (t *timeBudget) takeAvailable() time.Duration { </del> <ins> func (t *timeBudgetImpl) takeAvailable() time.Duration { </ins> t.Lock() defer t.Unlock() result := t.budget

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: bazel-test-master (periodic-kubernetes-bazel-test-master ) Which test(s) are flaking: gotest: Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --cc
/sig api-machinery
This is continuing to be flaky with more recent failure:
/assign Would you mind taking a look here? thanks! /triage accepted
- can we somehow uncover when this started happening? This test is very old and it seems it started happening very recently, so it would be helpful to see when this started happening...
Triage shows flakes starting ~Sept 30: Before Sept 30 it seems the job was flaking much less frequently.
Might be related to I will take a look.
It seems it's not related to that PR (neither to the previous: ) As there were already failures like that on Sep 24th (before this one was merged). I will take a deeper look.
OK - it's not related to any changes mentioned before. I can reproduce this particular failure by simply adding somewhere in this block: So it's probably connected to cpu-starvation at the test level and the solution is to switch to less aggressive timeouts. Will send out a PR.
Actually - it appeared to be slightly more subtle then that. But I already fully understand the problem. It's purely test issue, but require a bit more changes (and I won't get to it today/tomorrow). I will send a fix for that early next week.
- if that changes anything from your tracking perspective ^^
No board changes yet - the next stage is "Observing" once this issue gets closed :) If you have time - I'd love to pick your brain/understand the error more thoroughly though! Hoping you drop a good explanation in your PR next week
Thanks for sharing those insights, on your discovery of the solution to this bug.
It seems the PR didn't address that fully. Looking.
out for review
Change:
ctx, closeTransformers := context.WithCancel(serverCtx) defer func() { <del> // TODO: increment success metric when updatedEffectiveConfig=true </del> // TODO can work queue metrics help here? if !updatedEffectiveConfig { // avoid leaking if we're not using the newly constructed transformers (due to an error or them not being changed) closeTransformers() } <ins> if updatedEffectiveConfig && err == nil { metrics.RecordEncryptionConfigAutomaticReloadSuccess() } </ins> if err != nil { <del> // TODO: increment failure metric </del> <ins> metrics.RecordEncryptionConfigAutomaticReloadFailure() </ins> utilruntime.HandleError(fmt.Errorf("error processing encryption config file %s: %v", d.filePath, err)) // add dummy item back to the queue to trigger file content processing. d.queue.AddRateLimited(key)

Discussion:
ref - /sig auth
/triage accepted
/retitle encryption-at-rest: add success or failure metric when encryption configuration attempts to dynamically update
/assign