jiebi/CodeConvo huggingface dataset:
Change:
func topologyNormalizingWeight(size int) float64 { return math.Log(float64(size + 2)) } <ins> // adjustForMaxSkew adjusts the number of matching pods in a topology domain // using the constraint's maxSkew. // Topology domains with less than maxSkew number of pods are considered to have // the same priority. func adjustForMaxSkew(cnt, maxSkew int64) int64 { if cnt < maxSkew { return maxSkew - 1 } return cnt } </ins>

Discussion:
Spin-off from What would you like to be : Use maxSkew in TopologySpreadingContraint to affect relative weight of the constraint. Exact formula to be discussed. Some ideas: , intuitive but too coarse-grained at low numbers. Goes: 100%, 50%, 33%, 25%, 20% some linearity. For , goes: 100%, 66%, 50%, 40%, 33% . For , goes: 100%, 75%, 60%, 50%, 42% . Goes: 100%, 70%, 57%, 50%, 44% Why is this needed: When using for , it will be useful for operators to control how strong the constraints should be compared to explicit user requests. Pods would be able to control the weight of constraints per-topology.
/sig scheduling
1 maybe the most compatible option with the current zone:node ratio (2:1):
Not quite. The ratio is correct, but the weight is different. original: prop 1:
I realized that using as weight is quite counterintuitive. Instead, I propose that we use to water down the counts per topology. This way, the behavior still doesn't change for . But as increases, counts become more similar. For example, given the counts and , we get the new counts: . Then we proceed with the counts normalization as usual. Note that when the minimum count is zero in a topology, this procedure has the effect of giving the max score (100) for nodes (or zones) that would satisfy the condition. That won't be true when the minimum count is not zero, but enforcing it would be quite costly. This proposal still gets us closer to that and reduce score differentiation among nodes within the skew. When using constraints against multiple topologies, another side effect is that topologies with bigger would have a reduced effect in the overall score.
That sounds better than the initial proposal which seemed to deviate from the original semantics of the API.
WDYT ?
Sounds good to me. Per constraint on large-scope topology (e.g., zone), I assume it will still be credited with the matching number on its sub topologies (e.g., node), right? (It's just we're using the newCount formula - by taking the maxSkew specified on its constraint into consideration.)

Note that this doesn't replace increasing the weight as described in the parent issue. I think the issue title needs updating.
Understood. Default weight is tracked in another issue. This one talks about Scoring.
Right, just wanted to explicitly mention that to clarify the overall plan since this issue started in the context of increasing the default weight :)
Could you rename that one and clarify that it depends on this issue being resolved first?
can you clarify why that issue is dependent on this one? aren't we going to increase the weight regardless?
I was referring to . But you are right, it doesn't depend on this. kubernetes/enhancements does
Change:
ALL_OS_ARCH = $(foreach os, $(ALL_OS), ${ALL_OS_ARCH.${os}}) CFLAGS = -Os -Wall -Werror -static -DVERSION=v$(TAG)-$(REV) <del> KUBE_CROSS_IMAGE.linux ?= k8s.gcr.io/build-image/kube-cross KUBE_CROSS_VERSION.linux ?= $(shell cat ../build-image/cross/VERSION) KUBE_CROSS_IMAGE.windows ?= dockcross/windows-static-x64 KUBE_CROSS_VERSION.windows ?= latest KUBE_CROSS_IMAGE := ${KUBE_CROSS_IMAGE.${OS}} KUBE_CROSS_VERSION := ${KUBE_CROSS_VERSION.${OS}} </del> <ins> KUBE_CROSS_IMAGE ?= k8s.gcr.io/build-image/kube-cross KUBE_CROSS_VERSION ?= $(shell cat ../build-image/cross/VERSION) </ins> # NOTE(claudiub): The Windows pause image also requires the wincat binary we're compiling for the # port-forwarding scenarios. If it's no longer necessary, it can be removed.

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 --When including windows in a pause build I get a rate limit error as it tries to pull dockcross/windows-static-x64:latest. This causes the build to fail. This image should be stored and pulled from as there should be a copy of this in to mimic kube-cross for Linux images cd build/pause make all-push Kubernetes version : v1.20.1 Cloud provider or hardware configuration: N/A OS (e.g: ): Build running on Linux (includes cross compiling for windows) Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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 windows
Are you either of you able help with getting this image into the k8s gcr or if there is a reason why it can't be put there??
context - this might be due to use pulling from a small # of vmware VIPs
goal from sig-windows ~ move this into GCR eventually ~ would that be ok ?
do you know any history for this image?
That image carried over from the original work from . I have asked sig-testing previously if we could include that image's functionality into ` into the image. I can try this out in the morning, and if it works, I can send some PRs.
Seems to work. I have sent 2 PRs for this:
Change:
return maybeWrapSortingPrinter(cmd, printer), generic, nil } <ins> // PrintResourceInfoForCommand receives a *cobra.Command and a *resource.Info and // attempts to print an info object based on the specified output format. If the // object passed is non-generic, it attempts to print the object using a HumanReadablePrinter. // Requires that printer flags have been added to cmd (see AddPrinterFlags). func PrintResourceInfoForCommand(cmd *cobra.Command, info *resource.Info, f Factory, out io.Writer) error { printer, generic, err := PrinterForCommand(cmd) if err != nil { return err } if !generic || printer == nil { printer, err = f.PrinterForMapping(cmd, nil, false) if err != nil { return err } } return printer.PrintObj(info.Object, out) } </ins> func maybeWrapSortingPrinter(cmd *cobra.Command, printer kubectl.ResourcePrinter) kubectl.ResourcePrinter { sorting, err := cmd.Flags().GetString("sort-by") if err != nil {

Discussion:
What happened: What you expected to happen: yaml output How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: Related PR
Change:
make -C "${KUBE_ROOT}" test  WHAT="${WHAT:-$(kube::test::find_integration_test_dirs | paste -sd' ' -)}"  GOFLAGS="${GOFLAGS:-}"  <del> KUBE_TEST_ARGS="--alsologtostderr=true ${KUBE_TEST_ARGS:-} ${SHORT:--short=true} --vmodule=${KUBE_TEST_VMODULE}"  </del> <ins> KUBE_TEST_ARGS="--alsologtostderr=true ${SHORT:--short=true} --vmodule=${KUBE_TEST_VMODULE} ${KUBE_TEST_ARGS:-}"  </ins> KUBE_TIMEOUT="${KUBE_TIMEOUT}"  KUBE_RACE=""

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 --I wanted to run an integration test and use the option of to pass parameters to the program being tested. I could not find a way to do so. I tried but this failed because those args were followed by in the actual program invocation (see for the reason). I expected there to be a way. I expected it to be documented. Kubernetes version (use ): current and many recent releases 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 testing
/priority important-soon /triage accepted
/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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale just needs a rebase and another poke at assigned reviewers
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]:
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]:
/remove-lifecycle rotten
Change:
"fmt" "io" "net" <del> "strings" </del> "sync" "time"

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: Kubelet dies with a panic exception if CSI plugin returns NodeId == "" and nil error. Exception log see at the end of the message What you expected to happen: Kubelet should just raise an error to the plugin and ignore the registration. How to reproduce it (as minimally and precisely as possible): Create a CSI plugin with only Node that would implement GetNodeInfo as follows: Register it as a DaemonSet and see kublet crush Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.10-gke.17 Cloud provider or hardware configuration: GKE OS (e.g: ): Container-Optimized OS (cos) Kernel (e.g. ): - Install tools: Network plugin and version (if this is a network-related bug): Others: Related exception Related line of code: - no check whether error is not nil before calling Error() on it.
/sig storage
/sig node is this the version of the kubelet too? 14 is out of support. is the issue reproducible with a 1.15+ kubelet?
/assign
I checked the code - same defect still exists in current codebase.
thanks /priority important-soon
Wow, that was fast. Thanks!
Change:
// the considered volume spec spec     *volume.Spec readOnly bool <del> volume.MetricsNil </del> } var _ volume.Mounter = &flexVolumeMounter{}

Discussion:
kind feature What happened: Currently there is no mechanism to report metrics as the flex plugins are not enabled to collect metrics. All flex volumes lack this feature as compared to in-tree/built-in drivers even though it is possible to collect such metrics for most of the plugins. What you expected to happen: Depending on the availability of the metrics from the mounted FS, flex plugins should allow to report metrics for the FS. How to reproduce it (as minimally and precisely as possible): The default behavior that can be proved easily by just running a command similar to the following command on a node that is running a flex volume. This will show that there are no metrics collected for flex volumes. kubectl proxy $curl 127.0.0.1:8001/api/v1/nodes/<IP/proxy/stats/summary Environment**: Kubernetes version (use ): 1.12 Cloud provider or hardware configuration: local x86 OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux KubeStorage 4.4.0-130-generic -Ubuntu SMP Thu Jun 14 08:53:28 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: Others: /sig storage
+1 Yes, it will be good, if flex volume can support atleast the default metrics( i.e ), which most of the volume plugins support now. Based upon flex plugin "capabilities" parameters, it can be decided, whether the plugin supports "default metrics" or "nil metrics".
Change:
podCount            = 100 podCreationInterval = 100 * time.Millisecond recoverTimeout      = 5 * time.Minute <del> startTimeout        = 5 * time.Minute </del> <ins> startTimeout        = 3 * time.Minute </ins> // restartCount is chosen so even with minPods we exhaust the default // allocation of a /24. minPods      = 50

Discussion:
node-kubelet-serial Kubelet should correctly account for terminated pods after restart Since test was created, flakes 10-20% of the time. Not entirely clear why, I haven't looked. No response /assign /sig node
Introduced by , maybe we should use to replace See the log below, a pod becomes Succeed may exhaust tens of seconds
/triage accepted
Yeah I only tested this locally and not in CI, it seems that in CI the pods take much longer. Timings just need to be tweaked.
/reopen still a number of flakes since the attached PR merged, I don't think that fixed it.
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
from this link, I see all suites passed, which flakes do you mean?
I see this failure in
so this problem should have been fixed by
From gubernator: In all cases, it's timing out. I'll try upping the startTimeout.
/reopen still flaking
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
Luckily the kubelet log is clear as to what's going on. From (flake ) The test should work fine if we drop the CPU request a bit, let me tweak it to make up for the possible extra 100m scheduled. I'm not sure what's causing that (aren't these tests serial? what the heck is getting scheduled) but we should be resilient to it. Also, needs to be fixed. This test will no longer detect the regression it was designed to show after that change. I will revert it and also fix the resource requirements and that should fix this test.
/milestone v1.23 need to fix this before test freeze
Change:
} } } <ins> func TestSortInts64(t *testing.T) { src := []int64{10, 1, 2, 3, 4, 5, 6} expected := []int64{1, 2, 3, 4, 5, 6, 10} SortInts64(src) if !reflect.DeepEqual(src, expected) { t.Errorf("func Ints64 didnt sort correctly, %v !- %v", src, expected) } } </ins>

Discussion:
Ref and should sort revisions correctly (10 should be after 9, not 1).
I can help with this bug. Looks like trivial fix in PrintRolloutHistory
Thanks
are you still taking care of this one ? I am searching for some easy to do PR to just get familiar with the process and put my first PR in.
I created pr some time ago to close this issue
great thanks :-)
you can look for help-wanted issues or check and
thanks
Change:
err = cs.Pods(ns).Evict(e) Expect(err).Should(MatchError("Cannot evict pod as it would violate the pod's disruption budget.")) } else { <ins> // Only wait for running pods in the "allow" case // because one of shouldDeny cases relies on the // replicaSet not fitting on the cluster. waitForPodsOrDie(cs, ns, c.podCount+int(c.replicaSetSize)) </ins> // Since disruptionAllowed starts out false, if an eviction is ever allowed, // that means the controller is working. err = wait.PollImmediate(framework.Poll, timeout, func() (bool, error) {

Discussion:
Kubernetes version (use ): Found in CI Environment: Cloud provider or hardware configuration: AWS defaults What happened: https://k8s- is red, mostly because of the suite. It's probably a timing difference on AWS, but I'm trying to get AWS stable enough for the SQ, and this just isn't. c.f. , , , What you expected to happen: The suite should be green. How to reproduce it (as minimally and precisely as possible): It's constantly being reproduced.
[FLAKE-PING] This flaky-test issue would love to have more attention.
This test is about to enter the blocking category on SQ. Do you have time to look at this, or do I need to blacklist on AWS and find someone to fix the testing hole? I know I don't have the time right now.
how much do we care about this feature working on AWS? Can we disable it for now and fix at our leisure?
Is there anything special about AWS vs, say, on-prem, etc? My guess is that there's something minorly wrong with the timing here, based on looking at and from . It looks like it takes upwards of 20s-30s just to pull the image, so maybe a simple would fix this?
I can't imagine anything specific to the test that would vary based on provider. As you suggest, it's probably something ancillary like that the pods have not started.
Hmm... we actually already wait up to 10 minutes for at least one pod to be running. Perhaps we should wait until all pods are running before proceeding.
Oh, I see now. Yeah, I was misreading the failure, that's just roundtripping the itself.
No. Line 74 is waiting for the PDB to be updated, and it waits only 1 minute. The PDB won't be updated until all the pods are running. I have a PR that waits for all 3 pods to be running before proceeding with this test. Will send shortly.
[FLAKE-PING] This flaky-test issue would love to have more attention.
seems to have driven down the flakes dramatically, but there's a consistent flake on AWS for these tests: Any thoughts?
Change:
return fmt.Errorf("error parse ip address: %s", address) } if err := h.AddrDel(dev, &netlink.Addr{IPNet: netlink.NewIPNet(addr)}); err != nil { <del> return fmt.Errorf("error unbind address: %s from interface: %s, err: %v", address, devName, err) </del> <ins> if err != unix.ENXIO { return fmt.Errorf("error unbind address: %s from interface: %s, err: %v", address, devName, err) } </ins> } return nil }

Discussion:
https://k8s- https://k8s- cc: /priority failing-test
Sorry, but I will fix it ASAP.
/assign
PR is already sent. Wating for CI report...
Change:
}, }, { <del> name: "kernelVersion is 5.15.0, return safeSysctls with no kernelVersion limit and net.ipv4.ip_local_reserved_ports and net.ipv4.tcp_keepalive_time", </del> <ins> name: "kernelVersion is 5.15.0, return safeSysctls with no kernelVersion limit and kernelVersion below 5.15.0", </ins> getVersion: func() (*version.Version, error) { kernelVersionStr := "5.15.0-75-generic" return version.ParseGeneric(kernelVersionStr)

Discussion:
Add the following to be safe sysctls: net.ipv4.tcpfintimeout net.ipv4.tcpkeepaliveintvl net.ipv4.tcpkeepaliveprobes These are related settings to net.ipv4.tcpkeepalivetime that was enabled in These are related ipv4 TCP settings for tuning network connections between a client and a pod.
/sig network
May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node. /sig nodes 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
/sig node
I adjusted it with the plugin.
Would this change apply at the node level or the pod level? I assumed it would be at the pod level, and should not affect any other pods--however Kubernetes does not natively have any limits on network connections that I am aware of--but only the pod with the changed net settings would be affected.
To verify that a sysctl has an effect on other pods, we need to verify that it's a namespace sysctl.
Here's a simple test Use net.ipv4.tcpfintimeout sysctl to create a container check if it set on the host =It is the default value on host run another container attach to the network namespace of the one where the sysctl is set =results in sysctl being set Verify in another container under a different network namespace that it is not set =It is the default value According to the test results, net.ipv4.tcpfintimeout is a namespaced sysctl
I likewise verified and , which are also namespaced sysctl, and I believe we can add them to the safe sysctl /assign
Probably need to wait for to finish before start working on it
/triage accepted
Change:
<ins> - name: evictions_total subsystem: node_collector help: Number of Node evictions that happened since current instance of NodeController started. type: Counter stabilityLevel: STABLE labels: - zone </ins> - name: framework_extension_point_duration_seconds subsystem: scheduler help: Latency for running all plugins of a specific extension point.

Discussion:
I would like to propose the graduation of the metric from alpha to stable. The metric has been stable for 2 years now.
/sig api-machinery /sig instrumentation
I am willing to do all StabilityLevels from alpha to stable? Is that right?
/assign
- The request is to have the stability level for the metric graduate to stable. If there are other metrics you want to do at the same time that's a bonus, but not part of the request in this issue.
/sig node /remove-sig api-machinery /cc
To be promoted to stable, the metrics would need to be renamed from to in order to follow Prometheus best practices as well as sig-instrumentation naming guidelines.
/cc
/assign
/triage accepted
Change:
if err != nil { t.Errorf("Failed to create PersistentVolume %d: %v", i, err) } <ins> waitForPersistentVolumePhase(testClient, pvs[i].Name, watchPV, api.VolumeAvailable) </ins> } t.Log("volumes created")

Discussion:
That does not make any sense. should not exist at this point, it's from different integration test and starts with . Is it possible that that another test is running at this time? Each test basically starts with , so parallelism is IMO not possible as the tests will delete keys of each other.
So, it looks like the tests are not running in parallel, however some volumes leak from one test to another one, even past . I have no explanation for this, but I can reproduce it locally with logs I need. I have gut feeling that there is something wrong in the way how controller stops - each test starts a new one and stops it in the end. just closes some channels, there is no way how to wait until and finishes. I'll look at it on Monday, any ideas would be welcome.
The tests might be running in parallel - I think that's what does by default, though I'm not certain.
though that parallelism may only be across separate test suites, so is probably not run in parallel.
I bumped the priority to P0 since it is the main cause for kubernetes-test-go now, which blocks merge queue.
This issue is dropping our merge throughput by 60%...
I've made a quick patch which will at least test theory. I'll post it shortly.
Hm, now I see a failure in integration.TestUnschedulableNodes-- will keep my eye on it
There is an open issue for UnschedulableNodes - FYI
thanks for the PR. Did the test fail again after was merged?
I still see some failures of on my machine, fixed by