jiebi/CodeConvo huggingface dataset:
Change:
go_test( name = "go_default_test", <del> srcs = ["storage_test.go"], </del> <ins> srcs = [ "eviction_test.go", "storage_test.go", ], </ins> embed = [":go_default_library"], deps = [ "//pkg/apis/core:go_default_library", <ins> "//pkg/apis/policy:go_default_library", "//pkg/client/clientset_generated/internalclientset/fake:go_default_library", </ins> "//pkg/registry/registrytest:go_default_library", "//pkg/securitycontext:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library",

Discussion:
<!-- 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: When using the function from Python's Kuberneets API, we noticed that Pods are terminated bythe cluster without respecting their preStop hooks or terminationGracePeriodSeconds seconds. What you expected to happen: When using the eviction API, just as when using delete, Pods should be allowed to run their preStop hooks, as well as be given terminationGracePeriodSeconds before being terminated with SIGKILL. How to reproduce it (as minimally and precisely as possible): the following pod: the pod logs in another window to evict the pod. Here is a sample curl equivalent of what (1.13) is doing - happy path: Here is a sample curl equivalent of what Python's is doing (when not passed ) - broken path: The log output generated by the guinea pod on the happy path looks like this: The "Got signal 15" message shows up only after the preStop hook is finished, so ~10 seconds after the evict call is made What happens on the broken path is: We seem to be getting 2x SIGTERM, there are no messages indicating continued processing after the signal, and the signal itself is registered immediately after the eviction call is made, suggesting that preStop didn't run. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): CentOS Linux release 7.5.1804 Kernel (e.g. ): 3.10.0-862.14.4.el7.x8664 SMP Wed Sep 26 15:12:11 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: in-house Others:
/sig api-machinery
this is because of this code: invoked from here: it is passing in the eviction delete options field as-is, meaning nil gets propagated and defaulted to mean delete immediately. when calling delete APIs normally, delete options defaults to a non-nil empty set of options:
Fixed in
patch looks legit. Thanks for the quick reaction and for the pointers!
I've a elasticsearch stateful set which have a preHook which never completes and the pod is never killed despite terminationGracePeriodSeconds being set.

Is it related ? If so can this be considered to be cherry-picked on v1.13.x release branch ?
Change:
"//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//staging/src/k8s.io/apiserver/pkg/audit:go_default_library", <ins> "//staging/src/k8s.io/apiserver/pkg/authentication/user:go_default_library", </ins> "//staging/src/k8s.io/apiserver/pkg/endpoints/request:go_default_library", "//staging/src/k8s.io/apiserver/pkg/features:go_default_library", "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library",

Discussion:
Currently we don't have an easy way of determining what number of requests are apiserver self-requests. This has historically bitten us, since we used to have a 50(?) QPS limit on apiserver self-requests (which thus has been removed). Even so, it would be a good idea to know this generally, since this may be helpful in pinpointing performance regressions for apiserver. /sig api-machinery instrumentation
Can this issue be considered a newbie one? I'm hunting for issues which might be a good first PR.
In the triage meeting was mentioned that would be good to have similar issues to track other well known actors like controller-manager and kubelet. But let's keep this one for api-server calling itself to have it done. /cc
/cc
Change:
"os" "os/exec" "path" <ins> "strconv" </ins> "strings" "time"

Discussion:
Currently, kubelet uses a for communicating with cAdvisor. , were having an issue because we didn't realize making port available was required for kubernetes.
I prefer not do this since we plan to make 4194 publically reserved port for cAdvisor. Also cAdvisor is the default deamon running on every node of a kubernetes cluster. The issue you encountered sounds like a bad document issue we had for cAdvisor. We should fix the document instead of allow the port being configurable.
can you expound on 'bad document' issue?
Change:
scp -oLogLevel=quiet -oConnectTimeout=30 -oStrictHostKeyChecking=no -i "${LOG_DUMP_SSH_KEY}" "${LOG_DUMP_SSH_USER}@${node}:${scp_files}" "${dir}" > /dev/null || true else case "${KUBERNETES_PROVIDER}" in <del> gce|gke) </del> <ins> gce|gke|kubemark) </ins> gcloud compute copy-files --project "${PROJECT}" --zone "${ZONE}" "${node}:${scp_files}" "${dir}" > /dev/null || true ;; aws)

Discussion:
It seems that we stopped uploading logs to GCS around Friday/Saturday. As examples, this is the first kubemark-scale run that doesn't have logs: But we also don't have any logs e.g. for kubernetes-gce-e2e suite (which seems to be our main suite), e.g.: This seems to be the last run, for which we have logs: which suggests that it was broken around 2016-10-08 01:00:00
P0 - because it makes any debugging roughly impossible.
is working on this
It seems that after fixes from yesterday, we are still lacking logs from all kubemark runs.
Lack of kubemark logs is significantly slowing down any scalability-related work, which is our P0 goal for this quarter, so please prioritize it. - FYI ^^
As an example: [is a run from an hour ago] and it contains only file.
I'm going to migrate this job over to where our code (rather than a jenkins plugin) captures and uploads logs, which we want to do anyway and will hopefully resolve this. Odd... if we look at job/kubernetes-e2e-gce/configure we will a bunch of conditional build steps in the post-build actions configuration, which matches what is specified in yaml: We also have this specified in kubemark yaml: However I don't see where this is applied in the actual configuration: /job/kubernetes-kubemark-gce-scale/configure
I suspect that the job updater ran at some point this weekend while the conditional build step plugin wasn't working, so it wasn't able to add that step. I'm not sure why it hasn't rectified it since.
That seems to be the problem. I've cleared the job cache and done a full rebuild, so gce-scale and anything else that was updated why the postbuild plugin was missing should be fixed now.
Hmm - it doesn't seem to be fully fixed. Basically, we used to have logs from kubemark master machine, e.g.: (there is this kubemark-500-kubemark-master/ directory) However, even now (this is the last run), we no longer have those logs: So something is still broken...
Any thoughts about it? The logs are still missing, e.g.:
All the files in _artifacts are being properly uploaded.

Something else is failing to copy the logs onto the node. In In , it seems to be copying more: Did something else change in kubemark between these time periods? Is scp from the master broken now? This is a separate issue.
I'm not aware of any other changes. - we should try to debug it tomorrow.
We did touch recently in . Might be related.
Yeah, I was just trying to work out if it was. I tried to keep the fake path alive as best I could.
- if you could figure out if it was because of your PR (timing matches) that would be great...
I confirm that this is fixed now. - thanks a lot for fixing this!
Change:
newPod.Namespace = ds.Namespace newPod.Spec.NodeName = node.Name <ins> // DaemonSet pods shouldn't be deleted by NodeController in case of node problems. // Add infinite toleration for taint notReady:NoExecute here // to survive taint-based eviction enforced by NodeController // when node turns not ready. _, err = v1.AddOrUpdateTolerationInPod(newPod, &v1.Toleration{ Key:      metav1.TaintNodeNotReady, Operator: v1.TolerationOpExists, Effect:   v1.TaintEffectNoExecute, }) if err != nil { return false, false, false, err } // DaemonSet pods shouldn't be deleted by NodeController in case of node problems. // Add infinite toleration for taint unreachable:NoExecute here // to survive taint-based eviction enforced by NodeController // when node turns unreachable. _, err = v1.AddOrUpdateTolerationInPod(newPod, &v1.Toleration{ Key:      metav1.TaintNodeUnreachable, Operator: v1.TolerationOpExists, Effect:   v1.TaintEffectNoExecute, }) if err != nil { return false, false, false, err } </ins> pods := []*v1.Pod{} podList, err := dsc.podLister.List(labels.Everything())

Discussion:
When writing DaemonSets we decided that they shouldn't be deleted by NodeController in case of Node problems. Now that we're moving to using taints and taint-based evictions (NC will just taint Nodes and the rest will be done by generic taint-eviction mechanism) we need to add infinite toleration for those taints to DaemonSets to keep this behavior. cc
Off the top of my head, I think the best way to implement this is to modify the , to special-case DaemonSet pods and add infinite tolerationSeconds to them. (See definition of field in the API for how to do this.) do you think you can do this? It should be a simple change. cc/ BTW the feature Marek described will be alpha in 1.6, but nobody will be able to use it (without breaking DaemonSet) unless this request is implemented. So the 1.6 milestone tag is appropriate.
Why wouldn't the daemon set controller special case that?
Yeah, I guess that's probably better - have the DaemonSet controller create pods with the toleration.
I can do this, and yes, in the DaemonSet controller.
Change:
"k8s.io/kubernetes/pkg/apis/scheduling" kubelettypes "k8s.io/kubernetes/pkg/kubelet/types" "k8s.io/kubernetes/test/e2e/framework" <del> e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper" </del> imageutils "k8s.io/kubernetes/test/utils/image" "github.com/onsi/ginkgo"

Discussion:
It is unclear why the test needs the dynamic kubelet config. Need to clean it up. /sig node /priority important-soon /help Test is not a part of any testgrid. Need to understand why and return it back to the grid. Also it is marked as flaky. Need to be deflaked. unknown No response No response No response_ /sig node
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : ### Which jobs are failing? /priority important-soon /help ### Which tests are failing? 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
Hi, I am new to this project and would really love to start contributing and thought this might be a good start. Could you tell me a little more about this problem?
glad to have you, welcome! Some step by step you may start with: Find the test mentioned, understand what it is doing If dependency on DynamicKubeletConfig is found, try to work around them and remove that line. Try running the test locally. If you can repro flakiness - try to fix it If test passes: Try removing the and see if passes in serial tests on presubmits
Thank you so much!

/assign
/cc
it had a non-op config change in the past - - I potentially missed this when removing that
so, if I'd like to fix it, what should I do?
see Since we understood item 2 - it is not needed, just remove the skipper lines. Ideally test needs to be de-flaked as well, but it it not necessarily in the scope of this change
this is a simple issue, so I tried to fix it since I've found it some days.
Change:
padding: " ", want:    " a ", }, <ins> { noun:    "S", padding: " ", want:    " a ", }, { noun:    "O", padding: " ", want:    " an ", }, </ins> } for _, tt := range tests { if got := GetArticleForNoun(tt.noun, tt.padding); got != tt.want {

Discussion:
<!-- 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: add a CRD resource with kind only a single character while cause kube-apiserver crashslice bounds out of range What you expected to happen: add validation to limit CRD kind definition or fix the bug of slice out of bounds How to reproduce it (as minimally and precisely as possible): apiVersion: kind: CustomResourceDefinition metadata: name: spec: group: version: v1 names: kind: R plural: rs singular: r scope: Cluster Anything else we need to know?: apiserverlogs: 10:05:32. 6 ] Shutting down OpenAPI controller E6606 10:05:32. 6 ] Observed a panic: runtime.boundsError{x:-1, y:1, signed:true, code:0x3(runtime error: slice bounds out of range [-1:]) goroutine 1670 [running]: (0x41458a0, Gxc00ed66d40) /workspace/anago-v1.17.G- +0xa3 (0x0, 0x0, 0x0) /workspace/anago-v1.17.G- +0x82 panic(0x41458a0, Oxc0Oed66d40) +0x1b2 (0x7493232, 0x1, 0x447d778, 0x1, 0x130, 0xc00ed13680) /workspace/anago-v1.17.0- +0x2b8 ("builder).descriptionFor(€xc007b351f0, 0x0, 0x0, 0x4481982, 0x6, Gxc00ed06d00, 0x18) /workspace/anago-v1.17.0- +0x3c6 ("builder).buildRoute(GxcGG7b351fG, 0xc00ed66d00, 0x18, 0x0, 0x0, 0x447f0F3, 0x4, 0x447f71b, 0x4,

0x4481982, .) /workspace/anago-v1.17.0- .go :281 +0x197 (0xc66b7bcfd0, 0xc005d24a3c, 0x2, 0x101, 0x1, 0x2, Gxc60b76aec8) /workspace/anago-v1.17.0-rc .2.10+70132b0F130acc/src/k8s .io/kubernetes/output/dockerized/go/src/k8s .io/kubernetes/vendor/k8s .io/apiextensions-apiserver/pkg/controller/openapi/builder/builder .go :146 +0x49d (0xc66b7bcfd0, 0x0, Oxb, Gx447f1db, 0x4, 0x1) /workspace/anago-v1.17.0- +0x1a8 ("Controller).Run(0xc0012c8050, Gxc0G1d61200, 0xc007a6d1e0, 0xc069cced80) /workspace/anago-v1.17.0- +0x2da created by /workspace/anago-v1.17.0- .go :236 +0x244 panic: runtime error: slice bounds out of range [-1:] [recovered] panic: runtime error: slice bounds out of range [-1:] Environment: Kubernetes version (use ): 1.18.0 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig apps
/assign
There is a typo in the subject.
Change:
flags.StringVar(&TestContext.ReportDir, "report-dir", "", "Path to the directory where the JUnit XML reports should be saved. Default is empty, which doesn't generate these reports.") flags.Var(cliflag.NewMapStringBool(&TestContext.FeatureGates), "feature-gates", "A set of key=value pairs that describe feature gates for alpha/experimental features.") flags.StringVar(&TestContext.ContainerRuntime, "container-runtime", "remote", "The container runtime of cluster VM instances (remote).") <del> flags.StringVar(&TestContext.ContainerRuntimeEndpoint, "container-runtime-endpoint", "unix:///var/run/dockershim.sock", "The container runtime endpoint of cluster VM instances.") </del> <ins> flags.StringVar(&TestContext.ContainerRuntimeEndpoint, "container-runtime-endpoint", "unix:///var/run/containerd/containerd.sock", "The container runtime endpoint of cluster VM instances.") </ins> flags.StringVar(&TestContext.ContainerRuntimeProcessName, "container-runtime-process-name", "dockerd", "The name of the container runtime process.") flags.StringVar(&TestContext.ContainerRuntimePidFile, "container-runtime-pid-file", "/var/run/docker.pid", "The pid file of the container runtime.") flags.StringVar(&TestContext.SystemdServices, "systemd-services", "docker", "The comma separated list of systemd services the framework will dump logs for.")

Discussion:
NPD e2e Tests wouldn't start 12/08 suggested it may be related to /cc No response No response /sig node /priority important-soon
do you think you can take a look?
checked the logs for the latest failure, failing with the below message while starting kubernetes systemd probe
/triage accepted /assign can you please follow up with on this?
Compared the changelog, there are no changes in the kubernetes/node-problem-detector on the failure date.
I suspect this issue might be from the k8s-staging image. let me know if there is any one that could take a look at this issue related to the image used in infra.
The following are my theories there must be some change in the ssh secret keys that is resulting in the unexpected commit digest Image has some changes related to manifest pulling in docker and containerd. k8s-staging image - issue.
/reopen still failing
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
the test is green now. There was the recent PR from that fixed it
Change:
registry = "k8s.gcr.io/build-image", repository = "debian-base", # Ensure the digests above are updated to match a new tag <del> tag = "buster-v1.2.0",  # ignored, but kept here for documentation </del> <ins> tag = "buster-v1.3.0",  # ignored, but kept here for documentation </ins> ) container_pull(

Discussion:
What happened: The latest release of the debian-base image, v2.1.3, contains a vulnerable version of the apt package. CVE-2020- impacts apt version 1.8.2.1. What you expected to happen: Image should be updated to use at least apt 1.8.2.2 to clear the vulnerability. How to reproduce it (as minimally and precisely as possible):
/sig release
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
kube-proxy is using debain as base image. /assign Let me check other components
checked the base image in and I seems that no new debian or ubuntu official image is built for this CVE ?
That is correct, the purpose of this issue is to get a new image built and released, one which contains a resolution for the CVE.
per comments of @ tianon in Will update it once debain releases it.
Change:
// See https://github.com/open-telemetry/opentelemetry-go/tree/main/example/passthrough return otelhttp.NewHandler(wrappedHandler, "KubernetesAPI", opts...) } <ins> func getSpanNameFromRequestInfo(info *request.RequestInfo, r *http.Request) string { spanName := "/" + info.APIPrefix if info.APIGroup != "" { spanName += "/" + info.APIGroup } spanName += "/" + info.APIVersion if info.Namespace != "" { spanName += "/namespaces/{:namespace}" } spanName += "/" + info.Resource if info.Name != "" { spanName += "/" + "{:name}" } if info.Subresource != "" { spanName += "/" + info.Subresource } return r.Method + " " + spanName } </ins>

Discussion:
When enable apiserver tracing, the webhook request spans only show spanName as /, mostly because use http request operations as default span name, which is hard to understand. ! Following the open-telemetry standard of spanName, it's recommended to use as spanName. ! SpanName of webhook request should be , like ! APIServerTracing feature gates of apiserver a pod tracing dashboard No response <details18 </details<detailsNone </details<details</details<details</details<details</details<details</details
I make a fix for this.
/sig api-machinery instrumentation
Do you know if this is fixed in later versions of opentelemetry?
/triage accepted /assign
Looks like might be related
not yet, I think we can fix this in otel upstream, but it's hard to backport to otel , which is the version of otel used in Kubernetes
Good point. It think fixing it here is a good idea in that case.
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]:
/remove-lifecycle stale
could I take on this issue?
yes. Feel free to work on this.
! I test locally by 1.29 kubernetes and start a sample webhook, looks like the client span has already conforms to semantic conventions , which should be in the form of "HTTP {METHODNAME}"
! For apiserver as a server, now the spanName is still KubernetesAPI, which I think we could enhance it into "HTTP get_account/{accountId}" format
After digging for a while, I found one solution to implement this, I draft this idea in , could you help review about whether this is a correct way to implement it?
Change:
cc.Recorder, cc.ComponentConfig.AlgorithmSource, stopCh, <del> framework.NewRegistry(), </del> <ins> registry, </ins> cc.ComponentConfig.Plugins, cc.ComponentConfig.PluginConfig, scheduler.WithName(cc.ComponentConfig.SchedulerName),

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : As the is now implementable, it will be easier to add out of tree scheduler. And we are trying to use it to implement our plugins. The issue tracks following problems: Implement interface same as Custom Scheduler Plugins (out of tree)  to support out of tree scheduler Add support for scheduler to load and register user’s out of tree scheduling plugins that could be configured by admins. We could use to implement it, however it has some drawbacks as pointed out, e.g. We need find other ways, e.g. . /sig scheduling /assign
I did some investigation. It seems that is a better choice for the second part of this issue. I am making a prototype for it. Need I send a proposal at first? /cc
Just wrote a small proposal for it