jiebi/CodeConvo huggingface dataset:
Code change:
} ] }` ginkgo.By("Generate event list options") selector := fields.Set{ "involvedObject.kind":      "Node",

Related discussion:
text: Which jobs are failing: Which test(s) are failing: Since when has it been failing: Last successful run (23 Oct 2020, 10:07 PDT): First unsuccessful run (23 Oct 2020, 12:08 PDT): Testgrid link: Reason for failure: Anything else we need to know: presubmit job in repository also started to fail in the same fashion. Attempted to debug it myself, found out the following stuff: last successful run was accessing the apiserver via HTTP: all unsuccessful runs attempted to access the apiserver via HTTPS but to no avail: perused the history of to find out that the PR is almost certainly the reason of the failures (or rather uncovered some problem with the NPD or its tests): first, it coincides with the start of the failures of , second, we changed the default hostname of the apiserver in node tests in that PR. Judging by the code and the changes in the aforementioned PR I think that a quick mitigation would be to add a flag to the of these jobs. /assign /sig node /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
Opened for a mitigation that would make those jobs stop failing.
This won't work, unfortunately. Copying response:
I have filed to address this issue, but it seems I could not run the test in advance to verify my patch, did you know how to manually trigger the presubmit job?
Unfortunately I don't :/. My PR was also a wild guess. could you take a look at the proposed fix? Thanks once again for your help - really appreciated :).
the submission of hasn't fixed the problems, unfortunately :/. Sample failing run: We still have some peculiar problem related to health checking: and now NPD panics, too:
Thanks for your report, I believe the reason is admission controller has been disabled in node e2e tests: We need to figure out a new approach now. /reopen
Reopened this issue.
Code change:
} ] }` ginkgo.By("Generate event list options") selector := fields.Set{ "involvedObject.kind":      "Node",

Related discussion:
text: <detailsIn response to : Thanks for your report, I believe the reason is admission controller has been disabled in node e2e tests: We need to figure out a new approach now. 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
filed . I hope we could completely address this issue this time.
/milestone v1.20
Code change:
TemplateArgument: &tc.templateArg, AllowMissingKeys: tc.allowMissingKeys, } <ins> if !sort.StringsAreSorted(printFlags.AllowedFormats()) { t.Fatalf("allowed formats are not sorted") } </ins> outputFormat := "jsonpath" p, err := printFlags.ToPrinter(outputFormat)

Related discussion:
text: /kind bug What happened: When building kubernetes-1.7.0 packages for openSUSE, results differ for each build in and other man pages. coming from that uses and probably sets do not have any specific order, so it would need to be sorted on output. What you expected to happen: Every build should give identical results. See https://reproducible- for why this matters. How to reproduce it (as minimally and precisely as possible): See Anything else we need to know?: Environment: Kubernetes version: 1.7.0 OS (e.g. from /etc/os-release): openSUSE Tumbleweed
/sig release
somehow this bug seems to have been forgotten - can you help getting the right people to have a look?
- can you please confirm that PR works for you?
I tested it and it looks good.
/assign I enjoy reading my highlights to find the issue has already been addressed. :)
Sorry this wasn't addressed sooner. It does seem like it fell into a black hole, and pinging was the right way to resolve that. :)
/area build-release
related to /reopen
Reopening this issue. <detailsIn response to : related to 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
Code change:
protocol:            protocol, socket:              sock, timeout:             timeout, <ins> activeClients:       newClientCache(), </ins> sessionAffinityType: api.ServiceAffinityNone, // default stickyMaxAgeMinutes: 180,                     // TODO: parameterize this in the API. }

Related discussion:
text: Depends on UDP clients have a timeout (so we don't leak connections forever), but the test does not cover this. To do this, we probably need to track active connections, and plumb that all the way down to the goroutines spawned by the ProxyLoop routines. This is probably something we want to do anyway to be able to monitor.
Code change:
By("Before scale up finished setting 2nd pod to be not ready by breaking readiness probe") sst.BreakProbe(ss, testProbe) <ins> sst.WaitForStatus(ss, 0) </ins> sst.WaitForRunningAndNotReady(2, ss) By("Continue scale operation after the 2nd pod, and scaling down to 1 replica")

Related discussion:
text: https://k8s- do you know the statefulset owners?
cc
I did not see this happening until recently.
The controller misses that the first pod transitioned to unready and proceeds to create the second pod. The test uses a client to hit the api server and will scale up the statefulset as soon as the broken pod is observed but the controller uses caches so it may observe the scaled up statefulset quicker than the updated pod.
I will update the test to ensure that we wait until the unreadiness is observed on StatefulSet.Status.Replicas field prior to the scaling operation
SGTM
Code change:
func MakeDefaultErrorFunc(client clientset.Interface, podQueue internalqueue.SchedulingQueue, schedulerCache internalcache.Cache, stopEverything <-chan struct{}) func(pod *v1.Pod, err error) { return func(pod *v1.Pod, err error) { if err == core.ErrNoNodesAvailable { <del> klog.V(4).Infof("Unable to schedule %v/%v: no nodes are registered to the cluster; waiting", pod.Namespace, pod.Name) </del> <ins> klog.V(2).Infof("Unable to schedule %v/%v: no nodes are registered to the cluster; waiting", pod.Namespace, pod.Name) </ins> } else { if _, ok := err.(*core.FitError); ok { <del> klog.V(4).Infof("Unable to schedule %v/%v: no fit: %v; waiting", pod.Namespace, pod.Name, err) </del> <ins> klog.V(2).Infof("Unable to schedule %v/%v: no fit: %v; waiting", pod.Namespace, pod.Name, err) </ins> } else if errors.IsNotFound(err) { <ins> klog.V(2).Infof("Unable to schedule %v/%v: possibly due to node not found: %v; waiting", pod.Namespace, pod.Name, err) </ins> if errStatus, ok := err.(errors.APIStatus); ok && errStatus.Status().Details.Kind == "node" { nodeName := errStatus.Status().Details.Name // when node is not found, We do not remove the node right away. Trying again to get

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) Increase the log level of info logs to "v=2" when the scheduler or a node from its cache. 2) Increase the log level of info logs to "v=2" when the scheduler can't schedule a pod , , and add a log message for 2) report memory/cpu status of . Why is this needed: With cluster autoscaler now being used in production by some vendors, we want to have more visibility to events that could be related to the auto scaler to help debug customer issues. /sig scheduling /priority important-soon /assign
GitHub didn't allow me to assign the following users: congliu01. 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 : <!-- Please only use this template for submitting enhancement requests --1) Increase the log level of info logs to "v=2" when the scheduler or a node from its cache. 2) report memory/cpu status of . Why is this needed: With cluster autoscaler now being used in production by some vendors, we want to have more visibility to events that could be related to the auto scaler to help debug customer issues. /priority important-soon /assign </details
will consider this assigned to you.
/assign
Code change:
glog.Errorf("can't open %s, skipping this nodePort: %v", lp.String(), err) continue } <ins> if lp.protocol == "udp" { proxier.clearUdpConntrackForPort(lp.port) } </ins> replacementPortsMap[lp] = socket } // We're holding the port, so it's OK to install iptables rules.

Related discussion:
text: Hi, We have a device (router in this case) that sends long living stream of udp packets to our kubernetes cluster. We then create a service and pods that expose a node port to receive the incoming udp packets. However, packets were not reach our containers. Further digging and found that because UDP packets already stream into our host (therefore conntrack entry already created) BEFORE our service is created (iptable rules ), the iptable rule didn't take effect. Since our UDP stream is long living, the conntrack entry never get timeout neither. To workaround the issue, we have to stop the UDP stream for sometime after the service is created so that the conntrack entry times out. If we use "conntrack -D" to clear all entries after service is deployed also workaround the issue. Though it is the behavior of the linux iptable that new rules doesn't affect already existing connection, we are trying to see if kubernetes proxy have any config that can clear the related conntrack entries when a new service is deployed?
I am interested in your problem. Can you give some more details how did you add iptables rules before service started. Did you use the PREROUTING chain to forward port to pod ?
OK I was able to reproduce the problem
I think the issue is more problematic and complex. It is explained here:
Yes I think it is the same conntrack issue as in the one reported in docker issue. But I also think that the kubernetes might have a better control over it, since it knows the service up/down. I think k8s already deleting the conntrack entries when removing services. Just wondering if the same can apply to adding services?
Yes you are right. Kubernetes as a Docker manager should take care of this. Deleting the conntrack entries is done in very simple way: Just call the application
But there is another problem because I removed conntrack entries and then I created service and still have problem. I had to clear conntrack entries after I started my service. I will try add this to source code and then try it.
In code it looks much better. I assume you used for your service to use some particular port. The fix is in place when node port is binded. Do you think there is any other scenario where conntrack entries should be cleared?
Code change:
glog.Errorf("can't open %s, skipping this nodePort: %v", lp.String(), err) continue } <ins> if lp.protocol == "udp" { proxier.clearUdpConntrackForPort(lp.port) } </ins> replacementPortsMap[lp] = socket } // We're holding the port, so it's OK to install iptables rules.

Related discussion:
text: When I create PR I will let you know
The PR created: If you want verify it you can easily do it using local cluster Then clone kube-deploy project to create local k8s cluster with image you already created with fixes
Thanks for the fix. This is what we did manually to workaround so it should be good enough for us. It would be even better if you can clear the conntrack entry only for the affected entry, such as destination port, to minimizes the impact. Wondering if that possible? Will try out as well. Thanks.
I wanted do it like you mentioned but unfortunately conntract command doesn't give that possibilities. In parameters you can only pass the source and destination IP addresses.
Sorry didn't get back for a while. I tried the conntrack tool and seems like you can use --dport option: conntrack -D -s 172.27.209.165 -p udp --dport 53 udp 17 63 src=172.27.209.165 dst=171.70.168.183 sport= dport=53 src=171.70.168.183 dst=172.27.209.165 sport=53 dport= [ASSURED] mark=0 use=1 udp 17 33 src=172.27.209.165 dst=171.70.168.183 sport= dport=53 src=171.70.168.183 dst=172.27.209.165 sport=53 dport= [ASSURED] mark=0 use=1 conntrack v1.4.3 (conntrack-tools): 2 flow entries have been deleted.
Thanks for info I will try it
I've updated my PR for flag It works well
It's not clear to me why there would be a conntrack rule for your service port before we add any rules?
We have a router, which configured to export statistics using UDP to our host. That UDP stream is long live. If our host restarted, or we re-deploy our cluster (mainly during development), then udp packets received by host before K8S is provisioned.
But why do you have conntrack rules - simply receiving packets will not cause conntrack to create records.. , dachulin <:
Code change:
// TODO: This k8s-generic, well-known constant should be fetchable from another source, not be in this package KubeProxyClusterRoleName = "system:node-proxier" <ins> // KubeProxyClusterRoleBindingName sets the name for the kube-proxy CluterRoleBinding KubeProxyClusterRoleBindingName = "kubeadm:node-proxier" </ins> // KubeProxyServiceAccountName describes the name of the ServiceAccount for the kube-proxy addon KubeProxyServiceAccountName = "kube-proxy" <del> // KubeProxyClusterRoleBindingName sets the name for the kube-proxy CluterRoleBinding KubeProxyClusterRoleBindingName = "kubeam:node-proxier" </del> // KubeProxyConfigMapRoleName sets the name of ClusterRole for ConfigMap KubeProxyConfigMapRoleName = "kube-proxy" )

Related discussion:
text: kubeadm-kinder-latest ci-kubernetes-e2e-kubeadm-kinder-latest.Overall E2EKubeadm suite.[sig-cluster-lifecycle] [area-kubeadm] proxy addon kube-proxy ServiceAccount should be bound to the system:node-proxier cluster role 2021-11-09 23:32 CET () E2EKubeadm suite: [sig-cluster-lifecycle] [area-kubeadm] proxy addon kube-proxy ServiceAccount should be bound to the system:node-proxier cluster role This issue seems to be linked to FYI: /cc /sig cluster-lifecycle /area kubeadm
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
fix PR is here, needs LGTM:
Also failing on Thanks !
Code change:
// TODO: This k8s-generic, well-known constant should be fetchable from another source, not be in this package KubeProxyClusterRoleName = "system:node-proxier" <ins> // KubeProxyClusterRoleBindingName sets the name for the kube-proxy CluterRoleBinding KubeProxyClusterRoleBindingName = "kubeadm:node-proxier" </ins> // KubeProxyServiceAccountName describes the name of the ServiceAccount for the kube-proxy addon KubeProxyServiceAccountName = "kube-proxy" <del> // KubeProxyClusterRoleBindingName sets the name for the kube-proxy CluterRoleBinding KubeProxyClusterRoleBindingName = "kubeam:node-proxier" </del> // KubeProxyConfigMapRoleName sets the name of ClusterRole for ConfigMap KubeProxyConfigMapRoleName = "kube-proxy" )

Related discussion:
text: kubeadm-kinder-latest-on-1-22 E2EKubeadm suite.[sig-cluster-lifecycle] [area-kubeadm] proxy addon kube-proxy ServiceAccount should be bound to the system:node-proxier cluster role ci-kubernetes-e2e-kubeadm-kinder-latest-on-1-22.Overall task-06-e2e-kubeadm 2021-11-09 23:31 CET : E2EKubeadm suite: [sig-cluster-lifecycle] [area-kubeadm] proxy addon kube-proxy ServiceAccount should be bound to the system:node-proxier cluster role No response /sig cluster-lifecycle
/assign
/triage accepted will have a look and send a fix if it's kubeadm related.
/area kubeadm
fix PR is here, needs LGTM:
Code change:
if pv.Spec.CSI == nil || pv.Spec.CSI.NodeExpandSecretRef == nil { framework.Fail("creating pv without 'NodeExpandSecretRef'") } <ins> if pv.Spec.CSI.NodeExpandSecretRef.Namespace != f.Namespace.Name || pv.Spec.CSI.NodeExpandSecretRef.Name != secretName { framework.Failf("failed to set node expand secret ref, namespace: %s name: %s", pv.Spec.CSI.NodeExpandSecretRef.Namespace, pv.Spec.CSI.NodeExpandSecretRef.Name) } </ins> ginkgo.By("Expanding current pvc") newSize := resource.MustParse("6Gi")

Related discussion:
text: Seen in pull-kubernetes-e2e-gce-cos-alpha-features Specific job failure
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
from the error message I don't know if it refers to the sig-storage error or to the sig-auth one
/sig storage
/kind failing-test
/assign From : ... I am not sure if it's related:
is the culprit. cannot be used inside a . This only gets caught when the test actually runs, otherwise Ginkgo never sees the incorrect .
I don’t understand why sometimes it can get the pv by namebut sometimes it failed
but then is a sig-auth test , not storage , sorry /sig auth this seems that was recently in
/remove sig-storage
/assign /priority important-soon
/unassign
is still failed. seems not fixing the whole problem. /reopen feel free to close if the ci is green.
Reopened this issue. <detailsIn response to : is still failed. /reopen feel free to close if the ci is green. 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
the failure now looks like it is just a sig storage issue:
cc
/assign looks like the new test is still an issue
I think this line is the problem: When the test creates the object, it may take time for the PV to be provisioned and to be bound to the PVC. So you should do another before this call so you can get the latest PVC object with the bound PV.
I opened to get PVC again before using .
Only do PersistentVolumeClaims.Get() is not enough, whether we need to wait for sometimes to wait it bound? because sometimes the testcase is successful and sometime is failed.
If the Pod was able to run, then the PVC has to be bound.
so I can't understand why sometimes the testcase is successful and sometimes is failed.
Code change:
if pv.Spec.CSI == nil || pv.Spec.CSI.NodeExpandSecretRef == nil { framework.Fail("creating pv without 'NodeExpandSecretRef'") } <ins> if pv.Spec.CSI.NodeExpandSecretRef.Namespace != f.Namespace.Name || pv.Spec.CSI.NodeExpandSecretRef.Name != secretName { framework.Failf("failed to set node expand secret ref, namespace: %s name: %s", pv.Spec.CSI.NodeExpandSecretRef.Namespace, pv.Spec.CSI.NodeExpandSecretRef.Name) } </ins> ginkgo.By("Expanding current pvc") newSize := resource.MustParse("6Gi")

Related discussion:
text: By default, the DelayBinding is false, it will wait for PVC bound during creation. This is weird.
It waits for the claim to be bound, but the test case still needs to refresh its pvc object.
Because of the refresh is async, so after the pvc was bound, we need to get the pvc again, isn't it?
Code change:
v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" <ins> utilfeature "k8s.io/apiserver/pkg/util/feature" </ins> clientset "k8s.io/client-go/kubernetes" typedv1 "k8s.io/client-go/kubernetes/typed/core/v1" <ins> featuregatetesting "k8s.io/component-base/featuregate/testing" </ins> kubeapiservertesting "k8s.io/kubernetes/cmd/kube-apiserver/app/testing" <ins> "k8s.io/kubernetes/pkg/features" </ins> "k8s.io/kubernetes/test/integration" "k8s.io/kubernetes/test/integration/framework" )

Related discussion:
text: See for context. This issue is creating to track work on the API validation changes. Validation relaxation of certain fields in the pod spec to allow for mutable scheduling directives.
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
/assign
/sig scheduling
Docs PR:
Code change:
encoder := codecs.EncoderForVersion(info.Serializer, gv) return runtime.Encode(encoder, obj) } <del> // MarshalToYamlForCodecsWithShift adds spaces in front of each line so the indents line up // correctly in the manifest func MarshalToYamlForCodecsWithShift(obj runtime.Object, gv schema.GroupVersion, codecs serializer.CodecFactory) (string, error) { serial, err := MarshalToYamlForCodecs(obj, gv, codecs) if err != nil { return "", err } lines := strings.Split(string(serial), "n") var newSerial string for _, line := range lines { newSerial = newSerial + "    " + line + "n" } return newSerial, err } </del>

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: MarshalToYamlForCodecs adds an indent to the yaml output. This code can be combined with PrintBytesWithLinePrefix What you expected to happen: 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/assign rpothier
/sig cluster-lifecycle
/priority important-soon
Code change:
KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. LATEST=$(kube::release::semantic_version) <del> KUBE_GCS_NO_CACHING=n KUBE_GCS_MAKE_PUBLIC=y KUBE_GCS_UPLOAD_RELEASE=y KUBE_GCS_DELETE_EXISTING=y KUBE_GCS_RELEASE_BUCKET=kubernetes-release </del> <ins> KUBE_GCS_NO_CACHING='n' KUBE_GCS_MAKE_PUBLIC='y' KUBE_GCS_UPLOAD_RELEASE='y' KUBE_GCS_DELETE_EXISTING='y' KUBE_GCS_RELEASE_BUCKET='kubernetes-release' </ins> KUBE_GCS_RELEASE_PREFIX="ci/${LATEST}" <del> KUBE_GCS_LATEST_FILE="ci/latest.txt" KUBE_GCS_LATEST_CONTENTS=${LATEST} </del> <ins> KUBE_GCS_PUBLISH_VERSION="${LATEST}" </ins> source "$KUBE_ROOT/build/common.sh" MAX_ATTEMPTS=3 attempt=0 while [[ ${attempt} -lt ${MAX_ATTEMPTS} ]]; do <del> kube::release::gcs::release && kube::release::gcs::publish_latest && break || true </del> <ins> kube::release::gcs::release && kube::release::gcs::publish_ci && break || true </ins> attempt=$((attempt + 1)) sleep 5 done

Related discussion:
text: (cc Despite doing very, very similar things, doesn't rely on . It should, or the logic should otherwise be consolidated. I'm going to maybe work on this to make easier.
Code change:
// Status code 409 StatusReasonConflict StatusReason = "Conflict" <ins> // StatusReasonGone means the item is no longer available at the server and no // forwarding address is known. // Status code 410 StatusReasonGone StatusReason = "Gone" </ins> // StatusReasonInvalid means the requested create or update operation cannot be // completed due to invalid data provided as part of the request. The client may // need to alter the request. When set, the client may use the StatusDetails

Related discussion:
text: We sorta fixed this-- now it's a real status error, but we left the status code 500, so it still produces stack traces and potentially confuses clients. we should figure out the correct status code.
I think there is a lot more going on related to this in . Clients are re-listing after the error but not rewatching.
/sub
It turned out this was not causing job e2e flakes. Just sending 500s that were confusing. So lowering priority.
How about a NewBadRequest error?
that certainly sounds like an improvement.