jiebi/CodeConvo huggingface dataset:
Change:
// IsIgnorable returns true indicates scheduling should not fail when this extender // is unavailable. This gives scheduler ability to fail fast and tolerate non-critical extenders as well. <ins> // Both Filter and Bind actions are supported. </ins> IsIgnorable() bool }

Discussion:
I use extenders to add webhook for default-scheduler: And set to ignore scheuler error when scheduler extender is not working. But I got an error: . I suppose work fine in predicate path, but not work fine in bind path. The Ignorable logic in kube-scheduler: 637: and, 905: the is not judge in . Schedule should not error when set . extenders to kube-scheduler config(which has filterVerb and bindVerb and ignorable flag), example: and add config flag in kube-scheduler pod start up command. a scheduler-extender() and then stop it. a pod and you will see the schedule error. No response <details</details<detailsLocal environment </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling
/cc
/assign
Maybe this is not a bug but as designed, because bind is more critical than filter, what would you do in bind? I have no history context, cc
Hi, Kerthcet, in my scene, I use extender to bind IP(from my own network system) to my pod's annotaion. I'm aware of the critical of binding path, but, what If the extender is broken, how to skip it and continue? The scheduler extender design has supported ignorable, but only work for filter path make no sense for extender both has filter and bind. Maybe we can add an option to allow user to chose what can be ignored. Thanks for your reply anyway~
Reiterating the mentions to trigger a notification: <detailsIn response to : Maybe this is not a bug but as designed, because bind is more critical than filter, what would you do in bind? I have no history context, cc I'm aware of the critical of binding path, but, what If the extender is broken, how to skip it and continue?

The scheduler extender design has supported ignorable, but only work for filter path make no scence for extender both has filter and bind. Maybe we can add an option to allow user to chose what can be ignored. thanks for your reply anyway~ 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
So even the extender bind failed, will not impact your pod scheduling, right?
Yup
Right, if the field is there, we should support it. It's up to the cluster administrator to judge whether it makes sense to ignore a failed extender during bind.
Change:
} } <ins> redirectHandlerWithBody := func(s int, body string) func(w http.ResponseWriter, r *http.Request) { return func(w http.ResponseWriter, r *http.Request) { if r.URL.Path == "/" { http.Redirect(w, r, "/new", s) } else if r.URL.Path == "/new" { w.WriteHeader(s) w.Write([]byte(body)) } } } </ins> followNonLocalRedirects := true prober := New(followNonLocalRedirects) testCases := []struct {

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 --Used a HTTP probe with external redirect: Got warning: Kubelet logs show: Warning messages either show additional context or don't show . I would probably have expected or just Not a big deal, just a bit confusing message Apply yaml above Kubernetes version (use ): v1.22.0-beta.1 Cloud provider or hardware configuration: kind OS (e.g: ): linux Kernel (e.g. ): 5.10.40 Install tools: kind /sig node
According to See and
thanks! I am not concerned about the actual implementation behavior, but rather the event: . We should not have an event ending with as it denotes there is more information to follow, but there is not.
Got it. /assign
/triage accepted I send to fix this issue.
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]:
In 1.18 (because of EKS long term support I don't really want to get into), I get this: This is mildly aggravating, as it means I get fourteen lines of warning logs indicating that a service which exists solely to provide redirects is working as expected. Does this bug mean that I'll instead get an even more aggravating warning when I eventually upgrade? :) I found this bug while looking for a way to tell the probe that "getting a 308 or 302 or <insert one or a list of values heremeans success". It'd be ideal in my mind if the httpget probe allowed an "ok return values array" which accepted either single values or ranges, perhaps with a default value like .

The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
Change:
waitForContainerRemoval(fmt.Sprintf("%s_%s", pod1.Spec.Containers[0].Name, pod1.Name)) waitForContainerRemoval(fmt.Sprintf("%s_%s", pod2.Spec.Containers[0].Name, pod2.Name)) <del> // Skip rest of the tests if the number of allocatable CPUs < 2. if cpuAlloc < 2 { framework.Skipf("Skipping rest of the CPU Manager tests since the number of allocatable CPUs < 2") </del> <ins> // Skip rest of the tests if CPU capacity < 3. if cpuCap < 3 { framework.Skipf("Skipping rest of the CPU Manager tests since CPU capacity < 3") </ins> } By("running a Gu pod requesting multiple CPUs")

Discussion:
<!-- 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: Test failed when running CPU Manager node e2e test on Ubuntu 16.04 locally, and show this panic message: What you expected to happen: Tests passed. How to reproduce it (as minimally and precisely as possible): Run this node e2e test, use the following command: Anything else we need to know?: I think this is because the following codes: is . I will send a PR to fix this after it is confirmed. /sig node /assign PTAL, Thanks!
Thanks for the bug report. Reproduced successfully. It looks like the response body may have changed from empty map to null, which caused this to break. In any case, suggested adding the fix to his pending PR here:
Hi, have fixed this, lgtm.
Change:
assert.EqualValues(t, testTime(creationTime, seedPod0Infra).Unix(), ps.StartTime.Time.Unix()) checkNetworkStats(t, "Pod0", seedPod0Infra, ps.Network) checkEphemeralStats(t, "Pod0", []int{seedPod0Container0, seedPod0Container1}, []int{seedEphemeralVolume1, seedEphemeralVolume2}, ps.EphemeralStorage) <del> checkCPUStats(t, "Pod0", seedPod0Infra, ps.CPU) checkMemoryStats(t, "Pod0", seedPod0Infra, infos["/pod0-i"], ps.Memory) </del> <ins> if ps.CPU != nil { checkCPUStats(t, "Pod0", seedPod0Infra, ps.CPU) } if ps.Memory != nil { checkMemoryStats(t, "Pod0", seedPod0Infra, infos["/pod0-i"], ps.Memory) } </ins> // Validate Pod1 Results ps, found = indexPods[prf1]

Discussion:
/kind bug What happened: Testing is not working on master (commit ) on Mac running High Sierra and Go 1.9.2. Nil pointer dererefence in TestCadvisorListPodStats: What you expected to happen: Tests to pass. Compilation is all good. 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): MacOSX 10.13.2 Kernel (e.g. ): Install tools: Others:
/sig testing
/assign
Change:
Limits: v1.ResourceList{ v1.ResourceEphemeralStorage: *resource.NewQuantity(ephemeralStoragePerPod, "DecimalSI"), }, <ins> Requests: v1.ResourceList{ v1.ResourceEphemeralStorage: *resource.NewQuantity(ephemeralStoragePerPod, "DecimalSI"), }, </ins> }, } WaitForSchedulerAfterAction(f, createPausePodAction(f, conf), ns, podName, false)

Discussion:
What happened: I am questioning validity of the test. Comments under of say: The test scenario described as it is sounds reasonable. The only nitpick I have is the very first sentence saying "". Pod's resource limits are ignored in predicates. They take effect in the scoring phase when priorities are computed. Also, priorities are computed only when there are at least two candidate nodes. So after revisiting the step number 5 it's impossible to make sure the additional pod does or does not get scheduled when setting the resource limits. There are either no candidate nodes or one. In which case the limits are ignored and the test passes in the first case and fails in the second. In case there are at least two candidate nodes, one of them will always get picked. In which case the additional pod gets scheduled (no matter what the resource limits field says). In the framework: resource limits are accessed through method [1] is used to perform pre-scoring [2] in the scoring phase score is computed through method [3] The test is alternating between passing and failing state. It passes when predicates give empty list of candidate nodes and failing when the list of candidate nodes is non-empty. Thus, making the pod resource limits ineffective. [1] [2] [3] What you expected to happen: Have another node schedule the additional pod validating that all saturated nodes (with scheduled) have lower score (0 in case of plugin). Or, invalidate the test by removing it. Can anyone check the test validity and confirm/disprove my statement about ineffectiveness of the resource limits? How to reproduce it (as minimally and precisely as possible): Make sure there is at least one node with non-zero free cpu resource before running the step 5. Anything else we need to know?: Environment: Kubernetes version (use ): master HEAD Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
cc
I have noticed you refactored the test in Can you still recall the original intent of the test? I can't grasp how the limits are actually taken into account.
I agree, I think the test is wrong, the scheduler doesn't make fit decisions on resource limits. In the test, should have set. do you mind fixing the test and update the test comment please?
On it /assign
Change:
if route.LinkIndex == filterLinkIndex { continue } <del> if route.Src != nil { </del> <ins> if h.isIPv6 { if route.Dst.IP.To4() == nil && !route.Dst.IP.IsLinkLocalUnicast() { res.Insert(route.Dst.IP.String()) } } else if route.Src != nil { </ins> res.Insert(route.Src.String()) } }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /area ipv6 /area ipvs /sig network What happened: In an ipv6-only cluster with proxy-mode=ipvs the entries for NodePort in ipvs are created for ipv4 addresses. The target's (if there are any) consists of ipv6 addresses (wrongly) interpreted as ipv4; Attempts to use the NodePort with ipv6 addresses are black-holed. What you expected to happen: Ipv6 addresses to the nodes should be used for NotePort and the LB-targets shall be the ipv6 address of the pods. Traffic to NodePorts shall be distributed among the (ipv6) endpoints. How to reproduce it (as minimally and precisely as possible): Setup an ipv6-only cluster Create a service with type with endpoints Try to connect to the NodePort Do Anything else we need to know?: The nodes have both ipv4 and ipv6 addresses and it is possible that if the nodes only had ipv6 addresses it would work (I havn't tested). But even in an ipv6-only k8s cluster the nodes almost always need ipv4 addresses for other purposes. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Kvm VMs on Ubuntu 18.04.01 LTS OS (e.g. from /etc/os-release): Own BusyBox based system Kernel (e.g. ):Install tools: None Others:
The NodeIPs() function seem to return only ipv4 addresses.
I can't see why (yet) since is used in the GetLocalAddresses function
/cc Please give a hint before I dive into the netlink code.
This issue is used as an example here;
The functions filters on Src != nil . But ipv6 addresses seems to have Src == nil always. As it is this function will never return any ipv6 addresses.
Change:
selector: matchLabels: k8s-app: elasticsearch-logging <del> version: v7.4.2-1 </del> <ins> version: v7.4.3 </ins> template: metadata: labels: k8s-app: elasticsearch-logging <del> version: v7.4.2-1 </del> <ins> version: v7.4.3 </ins> spec: serviceAccountName: elasticsearch-logging containers: <del> - image: quay.io/fluentd_elasticsearch/elasticsearch:v7.4.2 </del> <ins> - image: quay.io/fluentd_elasticsearch/elasticsearch:v7.4.3 </ins> name: elasticsearch-logging imagePullPolicy: Always resources:

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: es-image as part of fluent-elasticsearch cluster addon does not build What you expected to happen: in the es-image folder should work How to reproduce it (as minimally and precisely as possible): cd cluster/addons/fluentd-elasticsearch/es-image make Anything else we need to know?: Environment: Kubernetes version (use ): 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:
/assign /triage accepted
/sig instrumentation
Change:
return } <del> ch <- metrics.NewLazyMetricWithTimestamp(s.StartTime.Time, metrics.NewLazyConstMetric(containerStartTimeDesc, metrics.GaugeValue, float64(s.StartTime.UnixNano())/float64(time.Second), s.Name, pod.PodRef.Name, pod.PodRef.Namespace)) </del> <ins> ch <- metrics.NewLazyConstMetric(containerStartTimeDesc, metrics.GaugeValue, float64(s.StartTime.UnixNano())/float64(time.Second), s.Name, pod.PodRef.Name, pod.PodRef.Namespace) </ins> } func (rc *resourceMetricsCollector) collectContainerCPUMetrics(ch chan<- metrics.Metric, pod summary.PodStats, s summary.ContainerStats) {

Discussion:
When scrape kubelet resource metrics provided by /metrics/resource, got response like this The metric containerstarttimeseconds's timestamp should not equals to container start time As above No response v1.24.7 Volc Engine No response No response No response No response_
I would like to take this up, after triage/accepted I just wanted to know then what time should be needed to be set there? /assign
the metric should not have a timestamp
If not timestamp, then what value and data type should I assign for the containerstarttime_seconds metric?
check
no need to change the value and data type, just remove the timestamp for the metric datapoint
Sure got it, raising a PR for the same!
If you have already done it, then why the PR is blocked and why I am redoing it again? Just curious to know!
Why do you think it's blocked and why are you redoing it before figuring this out?
/sig node
/triage accepted /priority important-longterm
/assign (since you sent a PR)
Change:
return reverseResult, nil } <ins> func trueMapPriority(pod *v1.Pod, meta interface{}, nodeInfo *schedulercache.NodeInfo) (schedulerapi.HostPriority, error) { return schedulerapi.HostPriority{ Host:  nodeInfo.Node().Name, Score: 1, }, nil } func falseMapPriority(pod *v1.Pod, meta interface{}, nodeInfo *schedulercache.NodeInfo) (schedulerapi.HostPriority, error) { return schedulerapi.HostPriority{}, errPrioritize } func getNodeReducePriority(pod *v1.Pod, meta interface{}, nodeNameToInfo map[string]*schedulercache.NodeInfo, result schedulerapi.HostPriorityList) error { for _, host := range result { if host.Host == "" { return fmt.Errorf("unexpected empty host name") } } return nil } </ins> func makeNodeList(nodeNames []string) []*v1.Node { result := make([]*v1.Node, 0, len(nodeNames)) for _, nodeName := range nodeNames {

Discussion:
<!-- 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?: What happened: A failed Prioritize Map Function caused Scheduler break down. What you expected to happen: Pod remains Pending and describe pod will show errors of failed functions. How to reproduce it (as minimally and precisely as possible): It happens when some prioritize's map functions return with error. Anything else we need to know?: Environment: Kubernetes version (use ): v1.9.6 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
As shown above, if priorityConfigs[i].Map(pod, meta, nodeInfo) returns with error, there will be no chance for results[i + 1] to initialize its value, thus causing panic when calling config.Reduce(pod, meta, nodeNameToInfo, results[i+1])
/sig scheduling
I opened a PR to initialize results with real host name instead of empty string.
Change:
} func TestGetFinishedTime(t *testing.T) { <ins> featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.SidecarContainers, true) </ins> defaultTestTime := time.Date(2009, time.November, 10, 23, 0, 0, 0, time.UTC) defaultTestTimeMinus30s := defaultTestTime.Add(-30 * time.Second) <ins> containerRestartPolicyAlways := v1.ContainerRestartPolicyAlways </ins> testCases := map[string]struct { pod            v1.Pod wantFinishTime time.Time

Discussion:
Today the function () only account for the regular containers finish time, presumably assuming that init containers have completed before before. However, with the sidecar (restartable init) containers, sidecar containers will always finish later than regular containers. And those needs to be accounted for the calculation. /kind bug The sidecar finish time will be accounted when calculating the job's finish time. Sidecar container with prolonged termination logic on a job will result in incorrect finish time reporting. /sig apps /priority backlog KEP:
/assign
/triage accepted
Change:
RUN ln -s /bin/sh /bin/bash RUN echo CACHEBUST>/dev/null && clean-install  <del> iptables  </del> <ins> ca-certificates  ceph-common  cifs-utils  conntrack  </ins> e2fsprogs  ebtables  ethtool  <del> kmod  ca-certificates  conntrack  util-linux  socat  </del> git  <ins> glusterfs-client  iptables  </ins> jq  <ins> kmod  openssh-client  </ins> nfs-common  <del> glusterfs-client  cifs-utils  ceph-common </del> <ins> socat  util-linux </ins> COPY cni-bin/bin /opt/cni/bin

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pods with volumeMount gitRepo volumes in 1.8.0 see the following error in kubelet logs (also in ) It is important to not that the git repo clone is done via ssh. I think what is happening is that hyperkube image now used to have command in it and now it does not have it. So the git clone command that kubelet runs fails with the above stacktrace since it cannot find . What you expected to happen: gitRepo is volume mounted. How to reproduce it (as minimally and precisely as possible): Reproducible in kubernetes 1.8.0+ hyperkube images. Anything else we need to know?: This probably is due to missing ssh binary in the new 1.8.0 hyperkube images. The commit might be an issue. Will comment further if I find otherwise. Environment: Kubernetes version (use ): =1.8.0 Cloud provider or hardware configuration**: Not Application. OS (e.g. from /etc/os-release): hyperkube base image Kernel (e.g. ): Install tools: Others:
How did you installed Kubernetes may I ask?
how does this help?
Normally, it is suggest to install kubelet as a daemon on host instead of using hyperkube container. cc you may be interested in this issue.
Need your help in identifying the fix here. I can send something for review. Suggestions are welcome.
The problem is that ssh isn't installed inside of the container. I don't know if it should be either, as the hyperkube image grows so large. If you install the openssh-client, it should work
Yes I did identify that as the problem if you see the description I mentioned. I pointed to a git commit that might have caused this. I am not sure what package installation has changed in the hyperkube container. "ssh" used to be available and now it is not. For the gitrepo feature to work it should be available.
Ah okay. If it was there before, we might want to add it back. SGTM.
Yeah, I switched the hyperkube image base from to our with some additional dependencies back. Apparently due to lack of volume + hyperkube test coverage, I've missed a number of dependencies needed.

cc
we could use dropbear as a replacement for just the ssh client?
I would prefer to use the openssh client over the dropbear client. It has wider usage and a stronger security track record IMO. The dropbear client also has somewhat different usage and configuration, so arguably using it is still a regression over the previous state. Saving a couple MB isn't worth using worse utilities, however much fun "dockerfile-golfing" is.
to fix
cherrypick to release-1.8:
This should be fixed in v1.8.3.
Change:
utilfeature "k8s.io/apiserver/pkg/util/feature" featuregatetesting "k8s.io/component-base/featuregate/testing" "k8s.io/utils/clock" <del> testingclock "k8s.io/utils/clock/testing" </del> "k8s.io/utils/pointer" )

Discussion:
A data race manifested in job link: NA NA No response No response No response /sig api-machinery
/cc
/assign
ack, fixing ...
/triage accepted
Change:
// DeleteOptionsApplyConfiguration constructs an declarative configuration of the DeleteOptions type for use with // apply. func DeleteOptions() *DeleteOptionsApplyConfiguration { <del> return &DeleteOptionsApplyConfiguration{} </del> <ins> b := &DeleteOptionsApplyConfiguration{} b.WithKind("DeleteOptions") b.WithAPIVersion("meta.k8s.io/v1") return b </ins> } // WithKind sets the Kind field in the declarative configuration to the given value

Discussion:
Most of the FooApplyConfiguration constructors pre-fill the Kind and APIVersion fields to make using them smooth. But () is missing this, making patterns like this fail: Currently this code fails with (server-side) error . The constructor should set the minimum required fields for the resulting object to be usable with calls, similar to how e.g. the `D Create a deployment (however) Create a clientset, and get the Deployments client from it Try to call deployments.ApplyScale using a ScaleApplyConfiguration created by the Scale() constructor I can see that the presence or absence of these metadata fields is driven by some code generation, but I wasn't able to follow through to what configures that code generation. I assume it's something in the schemas somewhere, but that wasn't clear to me. <details</details<detailsminikube v1.25.1 </detailsN/A N/A N/A N/A
/sig api-machinery
/assign /triage accepted
/assign