jiebi/CodeConvo huggingface dataset:
Change:
}, }), output: `Name:             bar <ins> Labels:           <none> </ins> Namespace:        foo Address: Default backend:  default-backend:80 (<error: endpoints "default-backend" not found>)

Discussion:
When command 'kubectl describe ing' Name: test-ing Namespace: practice Address: 10.10.01.10 Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found) TLS: test terminates Rules: Host Path Backends ---- ---- -------- / test-svc:80 (<none) Annotations: nginx Events: <noneResult has no information about labels. But Pod, Deployment, Service resources has label information like below. Name: test-room-test-mjsbz Namespace: test Priority: 0 Node: aks-test-test-test/22.22.222. Start Time: Fri, 09 Jul 2021 05:45:26 +0000 Labels: app=test pod-template-hash=test role=mediatest Why ingress has no information about labels? Actually when delete ingresss with labels is working correctly. Kubernetes version (use ): 1.18.14 Cloud provider or hardware configuration: AKS (Azure) OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig
/sig
/sig cli
/assign
/assign
/triage accepted /remove-kind bug /kind feature
Change:
expectReason: `forbidden sysctls`, expectDetail: `net.ipv4.tcp_keepalive_time`, }, <ins> { name: "new supported sysctls not supported: net.ipv4.tcp_fin_timeout", pod: &corev1.Pod{Spec: corev1.PodSpec{ SecurityContext: &corev1.PodSecurityContext{ Sysctls: []corev1.Sysctl{{Name: "net.ipv4.tcp_fin_timeout", Value: "60"}}, }, }}, allowed:      false, expectReason: `forbidden sysctls`, expectDetail: `net.ipv4.tcp_fin_timeout`, }, { name: "new supported sysctls not supported: net.ipv4.tcp_keepalive_intvl", pod: &corev1.Pod{Spec: corev1.PodSpec{ SecurityContext: &corev1.PodSecurityContext{ Sysctls: []corev1.Sysctl{{Name: "net.ipv4.tcp_keepalive_intvl", Value: "75"}}, }, }}, allowed:      false, expectReason: `forbidden sysctls`, expectDetail: `net.ipv4.tcp_keepalive_intvl`, }, { name: "new supported sysctls not supported: net.ipv4.tcp_keepalive_probes", pod: &corev1.Pod{Spec: corev1.PodSpec{ SecurityContext: &corev1.PodSecurityContext{ Sysctls: []corev1.Sysctl{{Name: "net.ipv4.tcp_keepalive_probes", Value: "9"}}, }, }}, allowed:      false, expectReason: `forbidden sysctls`, expectDetail: `net.ipv4.tcp_keepalive_probes`, }, </ins> } for _, tc := range tests {

Discussion:
Add the following to be safe sysctls: net.ipv4.tcpfintimeout net.ipv4.tcpkeepaliveintvl net.ipv4.tcpkeepaliveprobes These are related settings to net.ipv4.tcpkeepalivetime that was enabled in These are related ipv4 TCP settings for tuning network connections between a client and a pod.
/sig network
May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node. /sig nodes 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 node
I adjusted it with the plugin.
Would this change apply at the node level or the pod level? I assumed it would be at the pod level, and should not affect any other pods--however Kubernetes does not natively have any limits on network connections that I am aware of--but only the pod with the changed net settings would be affected.
To verify that a sysctl has an effect on other pods, we need to verify that it's a namespace sysctl.
Here's a simple test Use net.ipv4.tcpfintimeout sysctl to create a container check if it set on the host =It is the default value on host run another container attach to the network namespace of the one where the sysctl is set =results in sysctl being set Verify in another container under a different network namespace that it is not set =It is the default value According to the test results, net.ipv4.tcpfintimeout is a namespaced sysctl
I likewise verified and , which are also namespaced sysctl, and I believe we can add them to the safe sysctl /assign
Probably need to wait for to finish before start working on it
/triage accepted
Change:
NS="${8:-$NS}"          # namespace echo "Running w/ args: kubectl $kubectl version $VERSION sec $_SECONDS fe $FE lg $LG slave $SLAVE test $TEST NAMESPACE $NS" <ins> function create_ns { case "$NS" in "default" ) ;; "kube-system" ) ;; * ) cat << EOF > ns.json { "apiVersion": "v1", "kind": "Namespace", "metadata": { "name": "$NS" } } EOF $kubectl create -f ns.json esac } </ins> function create { cat << EOF > fe-rc.json

Discussion:
During the review of , it's better to also update and to use non-default namespace. cc .
cc
/ , I can continue to work on this one :).
/ , can you help to assign this issue to me? So I can trace the tasks in my hand :).
I'd be happy to assign you once you accept the invitation to the org. Do you plan to work on this now? If you're not actively working on it, I'd prefer to leave it unassigned.
, would you help to send the invitation ? Yes, I'd like to work on this now, that's a good start for me to learn example & e2e test suite :).
Already sent. Visit to accept. See
, I'm kuber now , thanks. I'm working on this now :). Checked and , openshift-origin is not using default namespace now; and we can update 's script to update namespace. But it seems and other example are still using default namespace, should we go through all example and update them accordingly?
, should I update all ns in one commit or one commit per example?
In which examples do you plan to make this change? cc
Making this change in some examples would be useful, but only if we explain why we're doing it. Additionally, linking to existing docs and blogs about namespaces would be helpful: I don't want to do this in all of the examples, because it does add an extra step, and labels also provide a means of managing a group of related resources within a namespace. Perhaps could recommend examples where this would make sense.
Change:
// CreateVolumeResource constructs a VolumeResource for the current test. It knows how to deal with // different test pattern volume types. func CreateVolumeResource(driver TestDriver, config *PerTestConfig, pattern TestPattern, testVolumeSizeRange e2evolume.SizeRange) *VolumeResource { <ins> return CreateVolumeResourceWithAccessModes(driver, config, pattern, testVolumeSizeRange, driver.GetDriverInfo().RequiredAccessModes) } // CreateVolumeResourceWithAccessModes constructs a VolumeResource for the current test with the provided access modes. func CreateVolumeResourceWithAccessModes(driver TestDriver, config *PerTestConfig, pattern TestPattern, testVolumeSizeRange e2evolume.SizeRange, accessModes []v1.PersistentVolumeAccessMode) *VolumeResource { </ins> r := VolumeResource{ Config:  config, Pattern: pattern,

Discussion:
For the ReadWriteOncePod feature to graduate to beta, we need to have E2E test coverage for its current alpha behavior. See this section of KEP-2485 for more context on what cases we need to cover for alpha: This is a requirement for beta graduation, see:
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 storage
Change:
glog.Infof("Using configuration file %s", *configFile) loadBalancer := proxy.NewLoadBalancerRR() <del> proxier := proxy.NewProxier(loadBalancer) </del> <ins> proxier := proxy.NewProxier(loadBalancer, *bindAddress) </ins> // Wire proxier to handle changes to services serviceConfig.RegisterHandler(proxier) // And wire loadBalancer to handle changes to endpoints to services

Discussion:
kube-proxy listens on all ports, but should be configurable. create a flag to specify which interface to listen on. Thanks for finding this bug.
For context, some providers apparently do external IPs by having a whole interface that gets 1:1 NAT without any firewalling. We do not want service ports on those interfaces. , Brian Ketelsen wrote:
Change:
// Run starts syncing instances from cloudprovider periodically, or create initial minion list. func (s *MinionController) Run(period time.Duration) { if s.cloud != nil && len(s.matchRE) > 0 { <del> go util.Forever(func() { s.Sync() }, period) </del> <ins> go util.Forever(func() { s.SyncCloud() }, period) </ins> } else { <ins> go s.SyncStatic(period) } } // SyncStatic registers list of machines from command line flag. It returns after successful // registration of all machines. func (s *MinionController) SyncStatic(period time.Duration) error { registered := util.NewStringSet() for { </ins> for _, minionID := range s.minions { <del> s.kubeClient.Minions().Create(&api.Minion{ </del> <ins> if registered.Has(minionID) { continue } _, err := s.kubeClient.Minions().Create(&api.Minion{ </ins> ObjectMeta:    api.ObjectMeta{Name: minionID}, NodeResources: *s.staticResources, }) <ins> if err == nil { registered.Insert(minionID) } } if registered.Len() == len(s.minions) { return nil </ins> } <ins> time.Sleep(period) </ins> } <ins> return nil </ins> } <del> // Sync syncs list of instances from cloudprovider to master etcd registry. func (s *MinionController) Sync() error { </del> <ins> // SyncCloud syncs list of instances from cloudprovider to master etcd registry. func (s *MinionController) SyncCloud() error { </ins> matches, err := s.cloudMinions() if err != nil { return err

Discussion:
gives but gives If minions were already in etcd from some previous launch of the apiserver/controller things work just fine no matter what the order. So to reproduce you have to clear everything from etcd before you try...
can you take a look at this? Probably just need to retry in background until etcd comes up?
Yep, there is no control loop for static machine config. Adding one should be trivial.
Blocked by Basically, apiserver returns inconsistent response.
I have observed a similar sort of thing, but what it appeared to be is more like the is not listening on it's socket at the time tries to connect to it and it never retries. So my work-around is to run before it like so: What I then observed is that the connection is indeed being refused at first attempt, but works on the second.
what do you see in the logs? I was seeing that it basically fails to connect to once and doesn't retry (although it said that it will try to retry).
should fix it, sorry for the trouble wondering where did you see that "it will try to retry"?
that wasn't the exact wording there... let me see if I can find out what exactly it said.
Ok, so what I'm seeing now is: I hope that PIDs would be a good enough proof to what order services have started up: I could provide some systemd graph dumps, but that would probably be too verbose, PIDs seem clearer. So really don't see how got //apisevercontroller-managerapiserver` didn't open the socket yet...
Change:
// ExpectedIptablesRule is the expected iptables rules with jump chain and match ipset name type ExpectedIptablesRule struct { <del> JumpChain string MatchSet  string </del> <ins> SourceAddress string JumpChain     string MatchSet      string </ins> } // ExpectedIPSet is the expected ipset with set name and entries name

Discussion:
Loopback addresses (127.0.0.0/8, ::1/128) can't be used by services in proxy-mode=ipvs it makes sense to dismiss those early, add RETURN rule to KUBE-NODE-PORT,KUBE-SERVICES No response <details</details25 <details</detailsnone <details</details<details</details<details</details<details</details
/sig network
As mentioned in , this is not a bug since the nodeport and ephemeral ranges overlap.
/kind cleanup /kind remove-bug
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /kind cleanup /kind remove-bug </details
/remove-kind bug
The title of this issue should be changed to something like; Which would indicate that this is not a bug fix but an improvement. Also remove the invalid use-case in the description and add references to comments in like I think to dismiss nodePort connects to localhost early for proxy-mode=ipvs is an improvement, and in the majority of systems traffic to localhost is more common than traffic to nodePorts so this change will also improve overall performance. This is not a fix for overlapping ephemeral and nodePort ranges! So if the title and description is not updated the correct triage is to close this issue as it violates the non overlapping rule for ephemeral/nodeport ranges, please see
/area ipvs
Ok, i will change issue title and descripiton
/triage accepted
Change:
if retries != 1 { t.Fatalf("%s: expected exactly 1 retry, got %d", job.Name, retries) } <ins> // await for the actual requeue after processing of the pending queue is done awaitForQueueLen(ctx, t, manager, 1) </ins> // the queue is emptied on success fakePodControl.Err = nil <del> manager.clock.Sleep(fastJobApiBackoff) </del> manager.processNextWorkItem(context.TODO()) verifyEmptyQueue(ctx, t, manager) }

Discussion:
pull-kubernetes-unit TestJobApiBackoffReset Unclear, test was last modified in June in Seen most recently in No response No response No response /sig batch cc
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### Which jobs are flaking? cc Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig apps /assign mimowo It could be related to ? Or maybe it was always flaky. just in case cc
/wg batch
Thanks for the heads up, I will take a look
Ok, I think I know the issue, which is very similar to another flaky test fixed in the past. The issue is when we shift the fake clock with during (invoked by ), which processes the pending queue () asynchronously. More details on the similar past issue: (). I was able to repro this manually by inserting short real-clock sleeps like here: I think the issue was introduced actually here by the use of fake clock: This commit was to master after 1.27 so no need for cherry-picking the fix. I think the fix is to call instead of , because it repeatedly shifts the fake clock after is processed.
Change:
}, "invalid-cross-namespace-affinity": { rq:        core.ResourceQuota{ObjectMeta: metav1.ObjectMeta{Name: "abc", Namespace: "foo"}, Spec: invalidCrossNamespaceAffinitySpec}, <del> errDetail: "must be 'Exist' when scope is any of ResourceQuotaScopeTerminating, ResourceQuotaScopeNotTerminating, ResourceQuotaScopeBestEffort, ResourceQuotaScopeNotBestEffort or ResourceQuotaScopeCrossNamespacePodAffinity", </del> <ins> errDetail: "must be 'Exists' when scope is any of ResourceQuotaScopeTerminating, ResourceQuotaScopeNotTerminating, ResourceQuotaScopeBestEffort, ResourceQuotaScopeNotBestEffort or ResourceQuotaScopeCrossNamespacePodAffinity", </ins> }, } for name, tc := range testCases {

Discussion:
On the document, the operator should be 'Exists' ! But in the Error message, it becomes 'Exist' ! the error message should be create a yaml and apply it It's my first time, I am not sure should we change to ? <details</details<detailsK3S </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 apps
/assign
/assign
Change:
ginkgo.By("Run a high priority pod that has same requirements as that of lower priority pod") // Create a high priority pod and make sure it is scheduled on the same node as the low priority pod. <del> runPausePodWithTimeout(ctx, f, pausePodConfig{ </del> <ins> runPausePod(ctx, f, pausePodConfig{ </ins> Name:              "preemptor-pod", PriorityClassName: highPriorityClassName, Resources: &v1.ResourceRequirements{ Requests: podRes, Limits:   podRes, }, <del> }, framework.PodStartShortTimeout) </del> <ins> }) </ins> preemptedPod, err := cs.CoreV1().Pods(pods[0].Namespace).Get(ctx, pods[0].Name, metav1.GetOptions{}) podPreempted := (err != nil && apierrors.IsNotFound(err)) ||

Discussion:
master-blocking kind-ipv6-master-parallel RuntimeClass should run a Pod requesting a RuntimeClass with scheduling without taints AdmissionWebhook [Privileged:ClusterAdmin] should honor timeout [Conformance] 01-27-2023 16:08 PST https://k8s- { failed [FAILED] timed out while waiting for pod runtimeclass-3517/without-label to be running In [It] at: @ 01/28/23 22:33:45.607 } No response kind 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
It looks like that “Kubernetes e2e suite: . Would we want to reopen this issue? I will keep a close eye on to see if it continues to flake.
Reopen to monitor failures cc
/sig node /cc
/retitle [It] [sig-node] RuntimeClass should run a Pod requesting a RuntimeClass with scheduling without taint
Example failure:
Failure The pod was created at , from the kubelet logs: so the pod started at , but it was deleted at because the 1 minute timeout was hit. It looks like the container startup took a while based on containerd logs: there is a gap there of and between and
It is hitting this timeout - That uses which is 1 min which seems to be too short. We should probably use or which is 5min or 2min, because the whole pod needs to start and it seems like 1min is too short in this case.
Change:
if ! which /usr/libexec/cockpit-ws &>/dev/null; then pushd /etc/yum.repos.d <del> wget https://copr.fedoraproject.org/coprs/sgallagh/cockpit-preview/repo/fedora-22/sgallagh-cockpit-preview-fedora-22.repo </del> <ins> curl -OL https://copr.fedorainfracloud.org/coprs/g/cockpit/cockpit-preview/repo/fedora-23/msuchy-cockpit-preview-fedora-23.repo </ins> dnf install -y cockpit cockpit-kubernetes popd

Discussion:
The latest vagrant always restarts nfs when nfs is used to share folders: This doesn't work with the default kube libvirt image: Attempting to restart nfs (systemctl restart nfs) on this image results in a failure from /usr/sbin/exportfs (invoked in the nfs unit file via ExecStartPre) of 'No file systems exported!' and this halts vagrant provisioning. To replicate (centos 7.1+vagrant 1.8.1+vagrant-libvirt 0.0.32):
This issue should be resolved by (already merged) and .
I marked as lgtm, so its basically blocked by the submit queue being fixed.
Change:
Help:      "Cumulative proxy rules Service changes", }, ) <ins> // IptablesRestoreFailuresTotal is the number of iptables restore failures that the proxy has // seen. IptablesRestoreFailuresTotal = prometheus.NewCounter( prometheus.CounterOpts{ Subsystem: kubeProxySubsystem, Name:      "sync_proxy_rules_iptables_restore_failures_total", Help:      "Cumulative proxy iptables restore failures", }, ) </ins> ) var registerMetricsOnce sync.Once

Discussion:
What would you like to be : kube-proxy should expose better metrics around tracking success and failures. Administrators should be able to alert on failure counts. Why is this needed: There are several motivating cases: iptables lock contention causes to fail at an increasing rate as services + endpoints grows or are failing to execute Ultimately, there is essentially no feedback from kube-proxy if it fails to program the service network. This makes it annoyingly difficult to debug when things go wrong. As many reasonable hints we can provide should be . /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
is anyone working one this..
what cases do you think are poorly covered? /assign
thanks for triaging this :-) The specific cases are when fails - that function logs an error but doesn't otherwise surface any information. We should have a top-level metric for failing, along with any other lower-level metrics that might make sense for administrators, e.g. fails, fails.
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/help-wanted
/assign
Change:
// We now wait for the minimum duration if at least one plugin asked to // wait (and no plugin rejected the pod) if statusCode == Wait { <ins> startTime := time.Now() </ins> w := newWaitingPod(pod, pluginsWaitTime) f.waitingPods.add(w) defer f.waitingPods.remove(pod.UID) klog.V(4).Infof("waiting for pod %q at permit", pod.Name) s := <-w.s <ins> metrics.PermitWaitDuration.WithLabelValues(s.Code().String()).Observe(metrics.SinceInSeconds(startTime)) </ins> if !s.IsSuccess() { if s.IsUnschedulable() { msg := fmt.Sprintf("pod %q rejected while waiting at permit: %v", pod.Name, s.Message())

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : metric name Description -- -- permitwaitduration_seconds Duration of permit extension point finishes waiting. Why is this needed: In permit extension point, if the status is "Wait", we block until the pod is scheduled or timeout: Blocking is an important behavior that we should monitor. /sig scheduling
/assign