jiebi/CodeConvo huggingface dataset:
Code change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/intstr" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/apimachinery/pkg/util/wait" "k8s.io/client-go/informers" clientset "k8s.io/client-go/kubernetes"

Related discussion:
text: /kind bug What happened: On a large cluster with enough pods, endpoints take as long as 10 minutes to show up after their associated pods and service are created. We believe that this is because every pod change results in an update of the addresses within the endpoint since they refer to a pod via a whose changes every time a pod change is observed. All these non-update updates eventually overwhelm the endpoint controller's queue rate limit and the queue starts to grow. While an increase in the queue's rate limit can alleviate the problem, an admin can keep a much lower limit if the non-update updates are dropped rather than processed. What you expected to happen: When a pod related to an endpoint is updated, I would expect the endpoint to update only if there is a change in the pod that relates to the endpoint, such as a change in the pod's IP address. How to reproduce it (as minimally and precisely as possible): a pod and associated service: the endpoint for changes: the watch running, and in another session, edit a pod to add a label: Then add another label on the line after the label, such as that the watched endpoint changed despite there not being any meaningful change to the fields the endpoint cares about. Anything else we need to know?: The PR addresses this issue. Environment: Kubernetes version (use ):
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 scalability
what ever happened with the effort to move leases off of Endpoints?
Code change:
healthchecker.mutationRequestChannel <- req } <del> func updateServiceListener(serviceName types.NamespacedName, listenPort int, addOrDelete bool) bool { </del> <ins> func updateServiceListener(serviceName types.NamespacedName, listenPort int, add bool) bool { </ins> responseChannel := make(chan bool) req := &proxyListenerRequest{ serviceName:     serviceName, listenPort:      uint16(listenPort), <del> add:             addOrDelete, </del> <ins> add:             add, </ins> responseChannel: responseChannel, } healthchecker.listenerRequestChannel <- req

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? Currently, the 4th parameter name of updateServiceListener in kube-proxy is addOrDelete, However, from the func caller, we just pass for AddServiceListener, and for DeleteServiceListener, So, I think the name addOrDelete is unreasonable. I prefer to change the parameter name addOrDelete to add so that avoid making people confused. In addition, there is a typo, We should change addition to deletion! Also, there is a sentence breaking, we should change from No Service Endpoints Not Found =No Service Endpoints are found Thanks!
Fixed!
Code change:
import ( "fmt" <del> netutils "k8s.io/utils/net" </del> "reflect" "testing" <ins> netutils "k8s.io/utils/net" </ins> utilipvs "k8s.io/kubernetes/pkg/util/ipvs" utilipvstest "k8s.io/kubernetes/pkg/util/ipvs/testing" )

Related discussion:
text: pull-kubernetes-unit ~1 day since merging of Test introduced in /sig network
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
/cc
ahhhg let me fix it
oh, I will take a look.
Code change:
_, client, closeFn := setup(t) defer closeFn() <del> _, err := client.CoreV1().RESTClient().Patch(types.ApplyPatchType). Namespace("default"). Resource("pods"). Name("test-pod"). Body([]byte(`{ "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "test-pod" }, "spec": { "containers": [{ "name":  "test-container", "image": "test-image" }] } }`)). Do(). Get() if err != nil { t.Fatalf("Failed to create object using Apply patch: %v", err) </del> <ins> testCases := []struct { resource string name     string body     string }{ { resource: "pods", name:     "test-pod", body: `{ "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "test-pod" }, "spec": { "containers": [{ "name":  "test-container", "image": "test-image" }] } }`, }, { resource: "services", name:     "test-svc", body: `{ "apiVersion": "v1", "kind": "Service", "metadata": { "name": "test-svc" }, "spec": { "ports": [{ "port": 8080, "protocol": "UDP" }] } }`, }, </ins> } <del> _, err = client.CoreV1().RESTClient().Get().Namespace("default").Resource("pods").Name("test-pod").Do().Get() if err != nil { t.Fatalf("Failed to retrieve object: %v", err) </del> <ins> for _, tc := range testCases { _, err := client.CoreV1().RESTClient().Patch(types.ApplyPatchType). Namespace("default"). Resource(tc.resource). Name(tc.name). Body([]byte(tc.body)). Do(). Get() if err != nil { t.Fatalf("Failed to create object using Apply patch: %v", err) } _, err = client.CoreV1().RESTClient().Get().Namespace("default").Resource(tc.resource).Name(tc.name).Do().Get() if err != nil { t.Fatalf("Failed to retrieve object: %v", err) } </ins> } }

Related discussion:
text: What happened: When running the apiserver returns an error: with being: What you expected to happen: The object being created if not found. How to reproduce it (as minimally and precisely as possible): get etcd up get apiserver up run kubectl apply (built from master as well) Anything else we need to know?: Everything built directly from master Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I think this is caused by We do need to fix that before alpha is released. The issue is that services use a custom storage implementation which doesn't support create-on-update and the first line of the update function checks that the object exists.
Okay, thanks for looking into it . Anything I can do here?
Code change:
func findProbe(probes []network.Probe, probe network.Probe) bool { for _, existingProbe := range probes { <del> if strings.EqualFold(*existingProbe.Name, *probe.Name) { </del> <ins> if strings.EqualFold(*existingProbe.Name, *probe.Name) && *existingProbe.Port == *probe.Port { </ins> return true } }

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /area cloudprovider /sig azure What happened: I've created a service of type in a Kubernetes cluster created via the ACS Engine. The load balancer has been created correctly after some time and a random NodePort (at this time ) has been allocated. However, in the Azure Portal I'm seeing that the health probe of that load balancer is pointing to port which does not exist in the whole Kubernetes system at all. Because of that wrongly configured health probe the load balancer is not reachable (i/o timeout). What you expected to happen: The health probe would have been configured to NodePort . How to reproduce it (as minimally and precisely as possible): Unfortunately, it does not behave always like this but only occasionally. In some cases the health probe gets configured correctly, but in others not. I've used the following manifest: Anything else we need to know?: When updating the health probe manually to the correct NodePort in the Azure portal, the load balancer starts to work properly. Environment: Kubernetes version (use ): 1.7.5 Cloud provider or hardware configuration: Azure Install tools: ACS Engine Others: -
Thanks for reporting the problem. Could you share the service spec after it is created? e.g. by running . And may I ask whether there is a service just removed with same name before this one?
Sure, thanks, please find the manifest below [1]. In fact I'll have some other services with the same name, but in other namespaces. In the namespace I didn't have a service named before. [1] Service manifest after creation
Filed PR , which should fix the problem. Need cherry-picked to v1.7 branch after it is merged.
Thank you very much that was really fast!
has been merged. created cherry pick PR for release 1.7.
Code change:
"runtime" "sort" "strings" <ins> "sync" </ins> "time" "github.com/golang/glog"

Related discussion:
text: There is a defer calling in this method: defer close(resultCh) It may crash the goroutine created at line 777, which then will make the whole kubelet crash. A simple fix Another simple fix
cc do you think this make sense?
You could just drop the channel and go with a mutex to update the set.
indeed.
Code change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/sets" <ins> "k8s.io/apimachinery/pkg/util/validation" </ins> utilfeature "k8s.io/apiserver/pkg/util/feature" cliflag "k8s.io/component-base/cli/flag" "k8s.io/component-base/logs"

Related discussion:
text: kubelet won't return error when invalid node labels are passed to flag, and node can't take part in a cluster. kubelet should return errors when invalid node labels are passed. You pass flag to kubelet (value is invalid), node doesn't take part in a cluster. ref. No response <details</details<detailsAWS </details<details</details<details</details<details</details<details</details
/sig node
/triage accepted
this should not be a breaking change as invalid labels make the kubelet unusable anyway. So better not even start the kubelet. /assign since there is a PR already
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Code change:
//   3 Standalone 'kubernetes' binary // Eventually, #2 will be replaced with instances of #3 func RunKubelet(kcfg *KubeletConfig) { <ins> kcfg.Hostname = util.GetHostname(kcfg.HostnameOverride) </ins> if kcfg.KubeClient != nil { <del> kubelet.SetupEventSending(kcfg.KubeClient) </del> <ins> kubelet.SetupEventSending(kcfg.KubeClient, kcfg.Hostname) </ins> } else { glog.Infof("No api server defined - no events will be sent.") } kubelet.SetupLogging() kubelet.SetupCapabilities(kcfg.AllowPrivileged) <del> kcfg.Hostname = util.GetHostname(kcfg.HostnameOverride) </del> cfg := makePodSourceConfig(kcfg) k, err := createAndInitKubelet(kcfg, cfg) if err != nil {

Related discussion:
text: Running the pre-built 0.8.0 binaries this flag does not work. Looks like the
I think that code happens only when setting up events, right? The hostnameOverride flag seems to still be there: what do you think about making this function take hostnameOverride as a parameter?
Yeah, it should fix the issue. Will fix it tonight.
Code change:
detect-project local kubectl="${KUBE_ROOT}/cluster/kubectl.sh" <del> "${kubectl}" delete pods heapster &> /dev/null || true "${kubectl}" delete pods influx-grafana &> /dev/null || true "${kubectl}" delete services influx-master &> /dev/null || true </del> <ins> local kubecfg="${KUBE_ROOT}/cluster/kubecfg.sh" "${kubecfg}" resize monitoring-influxGrafanaController 0 &> /dev/null || true "${kubecfg}" resize monitoring-heapsterController 0 &> /dev/null || true "${kubectl}" delete -f "${KUBE_ROOT}/cluster/addons/cluster-monitoring/" &> /dev/null || true </ins> if gcloud compute firewall-rules describe --project "${PROJECT}" monitoring-heapster &> /dev/null; then gcloud compute firewall-rules delete  --project "${PROJECT}" 

Related discussion:
text: examples/monitoring/influx-grafana- and friends NEED to be replaced by a replication controller ASAP. As it stands they are bad examples. Also, they should probably move to contrib/monitoring to match contrib/logging and contrib/dns
Code change:
result := c.client.client. Put(). <del> AbsPath(append(c.makeURLSegments(accessor.GetName()), subresources...)...). </del> <ins> AbsPath(append(c.makeURLSegments(name), subresources...)...). </ins> Body(outBytes). SpecificallyVersionedParams(&opts, dynamicParameterCodec, versionV1). Do()

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! If the matter is security related, please disclose it privately via --What happened: Providing an empty to the dynamic client's method results in a panic. What you expected to happen: An error should be returned on empty . How to reproduce it (as minimally and precisely as possible): Call with Anything else we need to know?: The expects a nonempty to be provided, but does not validate this. If an empty name is provided, this method will panic because it expects an , but the response will actually be an . Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: client-go 10.0.0
/sig api-machinery
Code change:
// TODO(resouer): think about lazily initialize this set invalidPredicates := sets.NewString() <del> oldTaints, oldErr := helper.GetTaintsFromNodeAnnotations(oldNode.GetAnnotations()) if oldErr != nil { glog.Errorf("Failed to get taints from old node annotation for equivalence cache") } newTaints, newErr := helper.GetTaintsFromNodeAnnotations(newNode.GetAnnotations()) if newErr != nil { glog.Errorf("Failed to get taints from new node annotation for equivalence cache") } </del> if !reflect.DeepEqual(oldNode.Status.Allocatable, newNode.Status.Allocatable) { invalidPredicates.Insert("GeneralPredicates") // "PodFitsResources" }

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?: /kind bug What happened: alpha suite has been failing in the BeforeSuite since 9/22 Did we recently enable some alpha taints feature?
It may be related to cc
/assign
, do you know how to trigger this test in CI, e.g. ?
I don't think there's a way to launch a ci job from here.
This seems to be the same failure as . You can trigger the GKE GPU tests on PRs using . GKE GPU tests use alpha features.
sure, let me add some instrument code and trigger test by ci :).
Code change:
return &Kubelet{ hostname:              hn, dockerClient:          dc, <del> cadvisorClient:        cc, </del> etcdClient:            ec, rootDirectory:         rd, resyncInterval:        ri,

Related discussion:
text: So today, cadvisor became wedged and just stopped paying attention to its socket. Not kubelet's fault. But when I would launch all I would get would be: It took me a bit of trolling through netstat and lsof to figure out that the problem was cadvisor being completely locked up. kill -9 cadvisor and everything started working well. I wonder if we should emit more messages during startup about what operation we are about to attempt, not just the results of operations, as I was blaming docker for a while....
kubelet shouldn't block on this. I'll take a look.
Any ideas what was locking cAdvisor? and was it just not responding to requests?
I don't have any idea why it was locked. If I find another one locked I'll hang onto it to debug. Journal had: obviously the 'kill' came from me. It would not respond to systemctl cadvisor stop. netstat looking at port 4194 showed me At which point I realized cadvisor wasn't handling its sockets right since so many long dead kubelet sockets hadn't been cleaned up, so I kill -9'd it.
I cut some interesting info from the cadvisor journal log (trying to cut hostnames) You can see the last message about failed to update stats for container ... happened Oct 08 01:06:01. It was then silent until I killed it Oct 08 19:20:13, even though I'm pretty sure dnf was still being launched every hour on the hour. So it was wedged for about 18 hours.
What kernel is this on? We've seen there is a kernel bug fixed in 3.12+ that sometimes hangs us forever on exit. We're not quite sure how it gets triggered...
16.3
Code change:
} }) <del> It("should invoke init containers on a RestartAlways pod", func() { </del> <ins> /* Release: v1.12 Testname: init-container-starts-app-restartalways-pod Description: Ensure that all InitContainers are started and all containers in pod started and at least one container is still running or is in the process of being restarted when Pod has restart policy as RestartAlways. */ framework.ConformanceIt("should invoke init containers on a RestartAlways pod", func() { </ins> By("creating the pod") name := "pod-init-" + string(uuid.NewUUID()) value := strconv.Itoa(time.Now().Nanosecond())

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Evaluating e2e tests based on available options which are covering important aspects with user scenarios and eligible to promote for conformance. What you expected to happen: These 4 e2e tests evaluate different and based on . [NodeConformance] should invoke init containers on a RestartNever pod [NodeConformance] should invoke init containers on a RestartAlways pod [NodeConformance] should not start app containers if init containers fail on a RestartAlways pod [NodeConformance] should not start app containers and fail the pod if init containers fail on a RestartNever pod Anything else we need to know?: comment, Are these tests good to promote for conformance or do we need to look on other aspects as well ? are observed api endpoint hits during tests execution. (API coverage improvement) - InitContainer [NodeConformance] should invoke init containers on a RestartNever pod InitContainer [NodeConformance] should invoke init containers on a RestartAlways pod InitContainer [NodeConformance] should not start app containers if init containers fail on a RestartAlways pod InitContainer [NodeConformance] should not start app containers and fail the pod if init containers fail on a RestartNever pod /area conformance cc
Reiterating the mentions to trigger a notification: <detailsIn response 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
Go ahead and open a PR to ask this question. Yes == PR is merged, no == PR is closed (or amended to doc the reason these tests can't be promoted)
Code change:
"//pkg/runtime:go_default_library", "//pkg/types:go_default_library", "//pkg/util/errors:go_default_library", <del> "//pkg/util/hash:go_default_library", </del> "//pkg/util/metrics:go_default_library", "//pkg/util/runtime:go_default_library", "//pkg/util/wait:go_default_library",

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Debian GNU/Linux 8 (jessie) Kernel (e.g. ): 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux What happened: Deployed a scheduled job from this manifest: After some time the jobs are no longer executed: What you expected to happen: Jobs are executed as defined in the manifest. How to reproduce it (as minimally and precisely as possible): Deploy a scheduled job and wait for some time.
Some logs from the controller manager:
Ping. More than 2 weeks and no action at all? Anything else i can do?
I'm also encountering this using both and as concurrency policies, fwiw.
I'm hitting this as well. Kube
Do the jobs start to reschedule if you delete old one? Try running . cc
From kube-controller-manager logs: The job is scheduled for 1:00. I think the "Multiple unmet start times" message is a clue of where things start going downhill. Also, notice how at 1:00 the controller wants to create job (for a whole day, it had failed on ).
Deleting (all) old jobs / pods fixes the problem temporarily. After some time the scheduled jobs face the same issue again.
There's a fix () that I've submitted against master to fix the Replace strategy, I'll mark it for inclusion in 1.4.
The other problem that I see here is this: It is possible that our is creating duplicates. I'll try to investigate that a bit more.
sorry for the delay in response time, I must have missed that while going through issues. Next time you're experiencing problems/have a question wrt Jobs/ScheduledJobs, just ping me directly in the issue.
No problem and I will. Thanks!
I'm still hitting this on
Fix in flight , I'll make sure to cherry-pick it back to 1.4
does this ship in to latest kubernetes release?
yes, this should be present in 1.5, 1.4 cherry-pick hasn't been merged yet.
so this issue is still present in v1.4.6?
Code change:
"//pkg/runtime:go_default_library", "//pkg/types:go_default_library", "//pkg/util/errors:go_default_library", <del> "//pkg/util/hash:go_default_library", </del> "//pkg/util/metrics:go_default_library", "//pkg/util/runtime:go_default_library", "//pkg/util/wait:go_default_library",

Related discussion:
text: yes - it is still present there. My fix was merged to 1.4 yesterday. You should wait for the next 1.4.x release.
thanks!
which according to should happen Dec 8th.
any news on the release?
See !msg/kubernetes-dev/o0At2-4KKQ8/_kPVM1XyDAAJ
so v1.4.7 will be released on that same day?
Look like should be available later today: !msg/kubernetes-dev/00lJpT9pxDc/YZfDzCxMDQAJ
Code change:
// Assume info is ready to process podStatus.Phase = getPhase(spec, info) <ins> podStatus.Info = api.PodInfo{} </ins> for _, c := range spec.Containers { containerStatus := info[c.Name] containerStatus.Ready = kl.readiness.IsReady(containerStatus) <del> info[c.Name] = containerStatus </del> <ins> podStatus.Info[c.Name] = containerStatus </ins> } <del> podStatus.Conditions = append(podStatus.Conditions, getPodReadyCondition(spec, info)...) </del> <ins> podStatus.Conditions = append(podStatus.Conditions, getPodReadyCondition(spec, podStatus.Info)...) </ins> netContainerInfo, found := info[dockertools.PodInfraContainerName] if found { podStatus.PodIP = netContainerInfo.PodIP } <del> // TODO(dchen1107): Change Info to list from map podStatus.Info = info </del> return podStatus, nil }

Related discussion:
text: Kubelet now only reports ContainerStatus. PodStatus / PodCondition is observed at master side based on a set of ContainerStatus. There is no other way to get PodIP except net container for master side. This is very confusion to the end user, , , ... Now we are finalizing on v1beta3 API, including PodStatus & ContainerStatus. We can make net container completely invisible to the end users by finishing the following steps: 1) Expose network related errors at API level 2) Generate PodStaus directly from Kubelet
3) once PodStatus generated by kubelet, PodIP can be removed from ContainerStatus.
I think reporting PodStatus rather than just container status is most important. How hard is that?
Used to be hard since there are many dependencies when I first report Status back. Now it is totally feasible. I already started to write PRs for this. :-)
One more PR required to close this one.