jiebi/CodeConvo huggingface dataset:
Code change:
func exportCustomMetricFromPod(f *framework.Framework, consumerName string, metricValue int) *common.ResourceConsumer { podAnnotations := map[string]string{ "prometheus.io/scrape": "true", <del> "prometheus.io/path":   "/Metrics", </del> <ins> "prometheus.io/path":   "/metrics", </ins> "prometheus.io/port":   "8080", } return common.NewMetricExporter(consumerName, f.Namespace.Name, podAnnotations, nil, metricValue, f.ClientSet, f.InternalClientset, f.ScalesGetter)

Related discussion:
text: <!-- 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: Used the endpoint /BumpMetric to create fake metrics for Prometheus. When I tried to curl /metrics I got the following response: Bad request. Not a POST request What you expected to happen: I expected to see something like this: # HELP info message. # TYPE gauge 0. How to reproduce it (as minimally and precisely as possible): Following the docs, after having it running inside kubernetes: Anything else we need to know?: Looks like introduced this by mistake. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig testing
Code change:
package route53 import ( <ins> "github.com/aws/aws-sdk-go/aws/awserr" </ins> "github.com/aws/aws-sdk-go/service/route53" "k8s.io/apimachinery/pkg/util/uuid"

Related discussion:
text: /kind bug What happened: walteraa [6:55 AM] Hi, The controller manager of the federation using Google cloud DNS is crashing, the log showed is that: the hyperkube command is that: I have created this in the Google DNS Someone knows why the DNS zone query is getting the 404 error?? :disappointed: What you expected to happen: It should have created the missing domain. How to reproduce it (as minimally and precisely as possible): As per above. Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.4 Cloud provider or hardware configuration**: OpenStack (irrelevant) OS (e.g. from /etc/os-release): irrelevant Kernel (e.g. ): irrelevant Install tools: irrelevant Others: irrelevant
The bug is related to this: The above code assumes that the provider code returns no error but an empty list if the domain does not exist, but instead the provider returns a 404. Need to fix the provider and/or the above code.
/sig federation
I am unlikely to have time to work on this soon, so if anyone else wants to, go right ahead.
/assign
An additional information: I have created a which is based on the credential JSON file created through instruction. After that, I have configured the Federation controller manager to mount this secret as a volume in the container and set the environment variable to the JSON file inside this volume. Before doing that, I was getting an authentication error so the google DNS provider couldn't be instantiated, and after doing the instructions that I mentioned before, this authentication error was solved but now I'm getting 404 error when Google DNS provider tries access the specified managed zone. The file that I have generated follow this structure:
Code change:
return info.HealthCheckNodePort } <ins> // GetNodePort is part of the ServicePort interface. func (info *BaseServiceInfo) GetNodePort() int { return info.NodePort } </ins> func (sct *ServiceChangeTracker) newBaseServiceInfo(port *v1.ServicePort, service *v1.Service) *BaseServiceInfo { onlyNodeLocalEndpoints := false if apiservice.RequestsOnlyLocalTraffic(service) {

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT What happened: When deleting/recreating pods backing a UDP service, traffic from external senders stops flowing. What you expected to happen: Traffic would continue to flow to new pods. How to reproduce it (as minimally and precisely as possible): Based on reading of similar issues and commit messages it seems like this would be most noticable on high-volume UDP applications, statsd and syslog are good examples. a deployment and service for a UDP app. In my test case, this would be the container. an external node, create a small test script utilizing a statsd library such as pystatsd. The most important part is that the sender uses the same source-port for every packet sent. Ex: the sender. Install tcpdump into the pod and watch for incoming packets, example from the test case: the pod tcpdump in the newly created pod. Observe that no new matching packets are flowing. existing conntrack rules on all nodes in the cluster. You should see traffic start flowing to the pod again. example command for clearing conntrack rules on the nodes: Anything else we need to know?: I have tested this only on GKE-managed clusters that utilize google forwarding-rules for external LBs, but I believe the issue may be present on any platform where iptables mode for kube-proxy is used. Tested and verified on 1.8.6-gke.0 and 1.7.11-gke.1. Also tested with both Google Container-optimized OS and the Ubuntu-based node images. I have only test this on GKE It appears this was a known issue and should have been cleared up by: From my reading of , it seems as if the func should exec() to clear up UDP entries on service endpoint change, but the only place I see that func called is from syncProxyRules(). That func looks complex and possibly like it is only run occasionally and not on service/endpoint changes. Environment: Kubernetes version (use ): (Also tested on 1.7.11-gke.1) Cloud provider or hardware configuration: GKE-managed clusters, google cloud. OS (e.g.
Code change:
return info.HealthCheckNodePort } <ins> // GetNodePort is part of the ServicePort interface. func (info *BaseServiceInfo) GetNodePort() int { return info.NodePort } </ins> func (sct *ServiceChangeTracker) newBaseServiceInfo(port *v1.ServicePort, service *v1.Service) *BaseServiceInfo { onlyNodeLocalEndpoints := false if apiservice.RequestsOnlyLocalTraffic(service) {

Related discussion:
text: from /etc/os-release): tried both: and Kernel (e.g. ): and Install tools: Others:
/sig network
We also ran into this in kubernetes v1.7.6 using OpenShift 3.7:
~I believe this is the same as ~If so, it is fixed in 1.10: These are about HostPort, not NodePort, sorry for the noise.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Is there any other known workaround for this besides updating conntrack rules on the kube nodes? I tried deleting and recreating the service, but this didn't update the rules. When I restart the stream on the client side data flows correctly again (perhaps it's perceived as a new connection), but I have to restart the stream for each sender.
/remove-lifecycle stale
FWIW, this is not fixed in 1.10 - that fix was for HostPort, and this is still a bug for NodePort.
I am seeing this issue in 1.11. I am using LoadBalancer type.
has been working on a fix for this, FYI.
This issue is extremely impactful for telephony protocols that rely on static source ip and source port. Any update on a possible workaround? I was thinking a potential workaround might be to reduce the UDP timeout to something really short so the stale conntrack entries go away faster. Or maybe there is a way to flush conntrack on the event of pod deletion? Edit: Removed stupid idea of a workaround to disable conntrack for UDP. Can't disable conntrack for UDP because it's used for DNAT from node to container.
The workaround is to not use NodePorts. Other kinds of services are already correct.
not sure what you mean. I am seeing the issue with a LoadBalancer type so it does not affect NodePorts only. As a workaround I have created a small python script that watches the K8s API for pod deletions and clears the related conntrack entries when that happens. I can share it when I get to work on Monday if you want to try it out.
Code change:
return info.HealthCheckNodePort } <ins> // GetNodePort is part of the ServicePort interface. func (info *BaseServiceInfo) GetNodePort() int { return info.NodePort } </ins> func (sct *ServiceChangeTracker) newBaseServiceInfo(port *v1.ServicePort, service *v1.Service) *BaseServiceInfo { onlyNodeLocalEndpoints := false if apiservice.RequestsOnlyLocalTraffic(service) {

Related discussion:
text: I've my script . Note that it's not tested much so don't use it in a production environment. Also it cleans up all conntrack entries for a deleted pod, not only the UDP related ones.
We are also seeing this issue with type loadbalancer. We are on 1.11. Our use-case is the following: multiple devices are sending to an aggreagator machine. This machine forwards the UDP packages to a loadBalancer in gcp. When debugging the service, I noticed the following: The traffic is assigned to one pod, and the packages are not loadbalanced (client and server are the same cfr use-case) When redeploying a new cluster, Conntrack is cleared on termination signal of the old pod. (client receives connection refused) red/black and highlander deployment strategies have the same effect. How would I expect this to be working then? New cluster is . Conntrack is cleared Data is routed to NEW pods old pods are terminated Best Regards, Tim
I am seeing this exact same issue on our cluster which has k8s v1.14.5 . We have endpoint nginx pods backing a UDP service with nodeport. Suddenly one day we see traffic not hitting into nginx pod but reaching the node hosting the nginx pod. We could simulate the problem by restarting the nginx pods. I am assuming with this issue marked as closed; and having made its way into v1.14; we should not be seeing this. Would also like to point out; the one thing, in addition we have in the service is ExternalTrafficPolicy set to Local. Can anyone please guide/help on why we are seeing this in v.1.14.5 of our cluster.
Seeing this with k8s v1.16.5
Code change:
kube::golang::setup_env <del> make -C "${KUBE_ROOT}" WHAT=cmd/genswaggertypedocs # Find binary genswaggertypedocs=$(kube::util::find-binary "genswaggertypedocs") if [[ ! -x "$genswaggertypedocs" ]]; then { echo "It looks as if you don't have a compiled genswaggertypedocs binary" echo echo "If you are running from a clone of the git repo, please run" echo "'make WHAT=cmd/genswaggertypedocs'." } >&2 exit 1 fi </del> _tmpdir="$(kube::realpath "$(mktemp -d -t swagger-docs.XXXXXX)")" function swagger_cleanup { rm -rf "${_tmpdir}"

Related discussion:
text: When working on I a strange issue. It seems that while auto-generating conversions it works fine, but during things like or in the presubmits what is generated is different. Looking into test results: it seems that the order in which the files are processed is different then. /kind bug /sig api-machinery
FTR: The log from above has some debug-logging and panics and the conversion-generator logs are those with
/assign
modifies conversion-gen, but doesn't change the generated files. Did you intentionally exclude those changes? I wonder if it's similar to I checked out , ran I was able to reproduce the error in If that's the case, a workaround to fix the auto-generating is to first remove the affected files and re-generate them locally.
This is supposed to be no-op :) no auto-generated files should change That's not the fix. The problem is with the test jobs themselves: for generating swagger doc, they actually generate different things than they generate when you call "make generated-files" My PR is only a trigger for the problem, it's not a root cause. The auto-generated files are correct, but as part of running swagger docs, we're in-process generating a different stuff.
It looks that packages were missing. has a shorter / list compared to the other checks (e.g. ) when I ran . In the case of , the component-base config package was missing, thus the FIXME code path got hit. The list of packages was derived from . It seems that the dir was dirty during . I'm exploring if we can clean up the dir like does.
It seems that this one isn't yet fully fixed. I have updated the based on the comments on it and a similar issue on that (which I think has a very similar root cause). However, now "govet" and "staticcheck" are failing: [Ironically all other tests are passing, so I think this is again connected to some garbage somewhere] - can you please help with this?
As previously, I can reproduce it by:
I'm fairly sure at this point that the inputdirs param here is too restrictive:
It seems that this commit might be addressing this:
Heh - I think it helped me locally, but it doesn't help for - I probably did something wrong. But I'm fairly sure it's something along those lines that we need to do.
Code change:
kube::golang::setup_env <del> make -C "${KUBE_ROOT}" WHAT=cmd/genswaggertypedocs # Find binary genswaggertypedocs=$(kube::util::find-binary "genswaggertypedocs") if [[ ! -x "$genswaggertypedocs" ]]; then { echo "It looks as if you don't have a compiled genswaggertypedocs binary" echo echo "If you are running from a clone of the git repo, please run" echo "'make WHAT=cmd/genswaggertypedocs'." } >&2 exit 1 fi </del> _tmpdir="$(kube::realpath "$(mktemp -d -t swagger-docs.XXXXXX)")" function swagger_cleanup { rm -rf "${_tmpdir}"

Related discussion:
text: - will you be able to help with it?
So yeah - I was completely wrong. Basically, running with with DBG it clearly is a problem with gen-conversion. And the problem is that we pass only limited input to it: I think we should always pass all inputs - but we should look a bit deeper into it.
OK - so this is the problematic part: We basically process only packages that are explicitly requested by the user and ignore ones that are imported. So in order to have the conversion func imported by the generator, the package where it lives has to be explicitly imported. So we should basically always pass all input packages to conversion generator.
I actually created a new one, as it seems to be a different thing. Closing in favor of
/triage accepted
Code change:
if err != nil { framework.Failf("Error getting node hostnames: %v", err) } <ins> ginkgo.By(fmt.Sprintf("Found %d SSH'able hosts", len(hosts))) </ins> testCases := []struct { cmd            string

Related discussion:
text: ci-kubernetes-e2e-gce-scale-correctness Kubernetes e2e suite: [sig-node] SSH should SSH to all nodes and run commands kubetest.Test Jul 10 14:01:51 UTC+0200 Kubernetes e2e suite: [sig-node] SSH should SSH to all nodes and run commands: more . Test /sig node
/cc
/triage accepted
Uhhh, this may help here
/milestone v1.22
/sig scalability FYI
I got annoyed that I couldn't click through to see the other logs, so now you can, ref: (spyglass doesn't render build- because it's 500MB, and the limit for rendering is 100MB)
/assign SIG Scalability chairs/TLs, please find someone to address or call this a non-release-blocking failure
Assigning to current scalability oncall (): /assign
This is sig-node issue - should be addres by SIG-node folks. /sig node
is being discussed as a fix for this and I'm not sure it's correct
is it sig scalability's intent that 5k node clusters should support SSH?
The SSH test in question passes in the "default" job: So the fact that this failure is unique to a scalability job means to me that scalability needs to own at least some part of this
I did a little bit of digging and ci-kubernetes-e2e-gce-scale-correctness uses option in kubetest, which according to seems to be setting KUBESSHBASTION env. So I believe this is main difference between our scalability job and "default".
Debugging the test in and providing a fix there. The crictl host PR () is doing something different.
Code change:
}) return args } <ins> func TestValidateKubeletFlags(t *testing.T) { tests := []struct { name   string error  bool labels map[string]string }{ { name:  "Invalid kubernetes.io label", error: true, labels: map[string]string{ "beta.kubernetes.io/metadata-proxy-ready": "true", }, }, { name:  "Valid label outside of kubernetes.io and k8s.io", error: false, labels: map[string]string{ "cloud.google.com/metadata-proxy-ready": "true", }, }, { name:   "Empty label list", error:  false, labels: map[string]string{}, }, } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { err := ValidateKubeletFlags(&KubeletFlags{ NodeLabels: tt.labels, }) if tt.error && err == nil { t.Errorf("ValidateKubeletFlags should have failed with labels: %+v", tt.labels) } if !tt.error && err != nil { t.Errorf("ValidateKubeletFlags should not have failed with labels: %+v", tt.labels) } }) } } </ins>

Related discussion:
text: xref In 1.16: change the metadata-proxy addon to use change the kube-proxy addon to use change the masq-agent addon to use stop setting , , and in kube-up
Hey I'm trying to start to contribute to kubernetes and this seem to be an easy task. Can I help with this one?
Code change:
} } <ins> // Check if the inspected image matches what we are looking for func matchImageTagOrSHA(inspected dockertypes.ImageInspect, image string) bool { // The image string follows the grammar specified here // https://github.com/docker/distribution/blob/master/reference/reference.go#L4 named, err := dockerref.ParseNamed(image) if err != nil { glog.V(4).Infof("couldn't parse image reference %q: %v", image, err) return false } _, isTagged := named.(dockerref.Tagged) digest, isDigested := named.(dockerref.Digested) if !isTagged && !isDigested { // No Tag or SHA specified, so just return what we have return true } if isTagged { // Check the RepoTags for an exact match for _, tag := range inspected.RepoTags { if tag == image { // We found a specific tag that we were looking for return true } } } if isDigested { algo := digest.Digest().Algorithm().String() sha := digest.Digest().Hex() // Look specifically for short and long sha(s) if strings.Contains(inspected.ID, algo+":"+sha) { // We found the short or long SHA requested return true } } glog.V(4).Infof("Inspected image (%q) does not match %s", inspected.ID, image) return false } </ins> // applyDefaultImageTag parses a docker image string, if it doesn't contain any tag or digest, // a default tag will be applied. func applyDefaultImageTag(image string) (string, error) {

Related discussion:
text: We had rather strange case today when after rolling update one of the kubelet's started wrong container. For this specific replicationcontroller we are using What happened was that after rolling-update when i started to debug the issue i discovered that one of the kubelet's did not pull the image: When looking into what image it actually started i saw: When checking from the actual node i saw this It seems that instead of starting myimage with tag 2208 kubelet started image tagged as 1393 since the docker image id starts with 2208.
Code change:
resources []string namespace string <del> name      string </del> <ins> names     []string </ins> defaultNamespace bool requireNamespace bool

Related discussion:
text: Currently, it could not delete multiple pods at once, need to delete them one by one, it's very inconvenient if I have tons of pods to delete. Unlike docker, docker can multiple stop/rm containers/images at once.
This is possible using label selectors as of , which is better if you have tons of pods.
I agree that using label selector is better to delete all of pods under the label. But to delete multile pods at once is still usable: I just want to delete 1/2 pods under the label, label selector will not work selector could not span over other selectors or pods Another reason is docker rm/stop x y z works, I will wonder why kubectl cannot. This is not urgent, but I hope it can be implemented.
I agree. Thanks for the suggestion.
Would this be a suitable task for someone new to k8s development? If so, I'd be willing to take a look at this, if someone could provide a couple of hints where to start.
Further to my last message, I have a functional work in progress I would like to share, if anyone is interested?
PRs are welcome. See
Yes, this is a reasonable place to start. Since its in the client, you won't get much orientation to the core server code, but it will be a good place to orient to the client side API. There us also prior art that you can model off of. The kubectl create ... command already supports multiple resources. A good command to adapter would be the 'label' command. You can find it in Many thanks in advance! Brendan On Feb 19, 2015 8:21 AM, "Eric Tune" wrote:
Code change:
if err := deployClient.Delete(deployment.ObjectMeta.Name, deleteOptions); err != nil { framework.Failf("failed to delete the deployment: %v", err) } <del> ginkgo.By("wait for 30 seconds to see if the garbage collector mistakenly deletes the rs") time.Sleep(30 * time.Second) </del> <ins> ginkgo.By("wait for deployment deletion to see if the garbage collector mistakenly deletes the rs") err = wait.PollImmediate(500*time.Millisecond, 1*time.Minute, func() (bool, error) { dList, err := deployClient.List(metav1.ListOptions{}) if err != nil { return false, fmt.Errorf("failed to list deployments: %v", err) } return len(dList.Items) == 0, nil }) if err != nil { framework.Failf("Failed to wait for the Deployment to be deleted: %v", err) } // Once the deployment object is gone, we'll know the GC has finished performing any relevant actions. </ins> objects := map[string]int{"Deployments": 0, "ReplicaSets": 1, "Pods": 2} ok, err := verifyRemainingObjects(f, objects) if err != nil {

Related discussion:
text: /priority failing-test /priority important-soon /kind flake /sig-api-machinery this failure is currently one of the top flake and repros in both Presubmits and CI jobs. This test is also part of the Conformance suite, which makes the flake far more critical. Can one of you please help triage this issue.
/cc
/cc
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
flakes are continuing, hopefully logging gives us more info to work with
this test seems to flake quite a bit in the presubmits and its a conformance test on top of this. Can we please look into the new logs to see if we have more info to deflake this? Triage: Logs: https://k8s-
/cc
FWIW this test seems to pass consistently in our conformance dashboards - https://k8s-,%20master%20(dev). But seems to flake only in CI and Presubmits
Do those run at different parallelism levels? It could be load/timeout sensitive
I have also seen a general uptick in flakes in other e2e tests that could be sensitive to watch event latency, not just gc tests - for example, see the failures in https://k8s-
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Hey, this test does not appear to be flaking anymore can we close this issue?
Closing based on non-response. /close
Closing this issue. <detailsIn response to : Closing based on non-response. 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 was never actually fixed, looks like.