jiebi/CodeConvo huggingface dataset:
Change:
if plugin.shaper == nil { return fmt.Errorf("Failed to create bandwidth shaper!") } <ins> plugin.ensureBridgeTxQueueLen() </ins> plugin.shaper.ReconcileInterface() }

Discussion:
I'm not sure where the defaults come from but they sometimes drop all packets causing container IPs to become unreachable. ARP fails. I'm not sure if this is related but I also noticed on this machine that the default pfifo qdisc drops all packets. pfifo is the default qdisc for an htb node so it's used in the unconfigured htb qdisc: This is because the default value for queue size is zero. On other machines I've seen the default value set to 1 packet and 1000 packets. When I set the limit explicitly the container becomes reachable again. The broken configuration is applied by kubelet to implement traffic shapping and there is no option to turn this off. This patch fixes the kubelet on broken machines by disabling traffic shapping: cc
does this happen with --configure-cbr0 and packet shaping too? The kubenet implementation just uses the existing kubernetes shaping code that --configure-cbr0 does.
It seems the *fifo qdiscs default their packet limit to the txquelen of the interface (man tc-pfifo). It also seems most virtual interface types (bridge, etc) set a dev-txqueuelen of 0. It further seems that relies on the default packet limit. I could swear this worked before with kubenet, and it must have worked with --configure-cbr0 when the code was originally . I'll check around to figure out what the default limit should be for interfaces that don't specify a tx queue length.
Note that to test with --configure-cbr0 you'd also need --reconcile-cidr.
Upstream CNI fix is here: and we'll also work around it in kubenet for now.
FWIW, the upstream CNI fix got merged for CNI 0.3.0
Change:
} now := metav1.Now() badValue := "spaces not allowed" <ins> badAPIGroup := "example.com/v1" goodAPIGroup := "example.com" </ins> scenarios := map[string]struct { claim        *resource.ResourceClaim

Discussion:
Following YAML file is accepted without error. Notice the field, it is an instead of , containing character. This can lead to an issue when resource driver generates structured parameters' in-tree object with being just without version. The DRA scheduler plugin will try to match the parameters object based on the reference here: In latest master the code appears to use an indexer, and the issue might be hidden, if applicable at all. I did not check the reproducibility in master yet. However, main question is whether the should allow value with character in general. An error is expected from the apiserver upon object creation request, reporting that APIGroup containes APIVersion. Maybe. Have any resource driver that supports structured parameters, , for instance, also puts (gpucrd.APIGroup) value into . v1.30.1 <details</details<details</details<details</details<details</details<detailsscheduler's dynamicresources plugin </details
/sig node /triage accepted
/assign
Change:
for_test = [ ":kubernetes-test-portable.tar.gz", ":kubernetes-test-{OS}-{ARCH}.tar.gz", <del> # TODO(ixdy): remove once the "mondo-test" tarball is deprecated. # It isn't really mondo under Bazel anyway. ":kubernetes-test.tar.gz", </del> ], ), )

Discussion:
What happened: On 2019-02-22 was merged with an indication that the mondo test tarball noted as deprecated as per But it did not include a timeline for eventual removal. What you expected to happen: It's been 7 months now. We should formalize a plan for removal. /sig testing /sig release /kind cleanup /priority important-soon
Enhancement tracking issue ref:
removes the deprecated mondo test tarball.
Change:
// Allow RSA format only k, ok := privKey.(*rsa.PrivateKey) if !ok { <del> return nil, nil, errors.Wrapf(err, "the private key file %s isn't in RSA format", privateKeyPath) </del> <ins> return nil, nil, errors.Errorf("the private key file %s isn't in RSA format", privateKeyPath) </ins> } p := pubKeys[0].(*rsa.PublicKey)

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 trying to deploy Kubernetes using kubeadm v1.12.1, kubeadm failed to generate certificates, causing it to fail at a later step. After passing to get all the logs I could I found that it was expecting all the certificates to have been pre-made, even though I only the certificate and key for the certificate authority. So I dug into the code, and in I found this: It turns out all the PKI I've been generating for things like etcd has been ECDSA. So I found the issue I was having, but I still couldn't figure out why kubeadm wasn't failing right away. I took a look at the caller of that function: It looks like that original error is swallowed. What you expected to happen: Immediate failure when keys are in the wrong format. How to reproduce it (as minimally and precisely as possible): Use an ECDSA cert/key pair and run . Anything else we need to know?: Environment: Kubernetes version (use ): v1.12.1 Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): Ubuntu 18.04 Kernel (e.g. ): 4.15.0-34-generic -Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
Please create a issue on
/area kubeadm /sig cluster-lifecycle
Sure.
Change:
} // create pod which using hostport on the specified node according to the nodeSelector <del> func creatHostPortPodOnNode(f *framework.Framework, podName, ns, hostIP string, protocol v1.Protocol, nodeSelector map[string]string, expectScheduled bool) { </del> <ins> func creatHostPortPodOnNode(f *framework.Framework, podName, ns, hostIP string, port int32, protocol v1.Protocol, nodeSelector map[string]string, expectScheduled bool) { </ins> createPausePod(f, pausePodConfig{ Name: podName, Ports: []v1.ContainerPort{ { <del> HostPort:      80, </del> <ins> HostPort:      port, </ins> ContainerPort: 80, Protocol:      protocol, HostIP:        hostIP,

Discussion:
The test uses port 80, which is often in use on clusters (in our case, masters have an ingress controller listening on 80). The test should use something in the high range that is unlikely to conflict or use a smarter algorithm for finding a port to validate. fails in openshift
I am looking into it.
I looked into the test and it seems that another option would be for the test to not use 127.0.0.1 to avoid such conflict with infra (or any other important) pods on 127.0.0.1. As the test is using 127.0.0.1 and 127.0.0.2, I think we could just use 127.0.0.2 and 127.0.0.3 instead.
so it seems there are following options we can use: 127.0.0.2 and 127.0.0.3 instead of 127.0.0.1 and 127.0.0.2. pick some high random port number. something like following to pick unused port: and then extract random port from it.
with option 1 as it seems safer than 2 to me. Let me know if there is any concern, or if we would want to go with 2 or 3 option or something else.
Change:
) func init() { <ins> // Prevent memory leak from OTel metrics, which we don't use: // https://github.com/open-telemetry/opentelemetry-go-contrib/issues/5190 otel.SetMeterProvider(noop.NewMeterProvider()) } func init() { </ins> install.Install(cfgScheme) }

Discussion:
Since updating from Kubernetes 1.26. to 1.29. we experiences OOM-Kills on control plane nodes. After some investigation we found that adding to the fixed the issue. (Found this via pprof/heap of one apiserver: heap dump could be if needed) Before the update to 1.29.* the control planes were running with 4GB of memory with the same worklow in the cluster without issues. After the workarround using the feature gate the memory consumption of the whole control plane is not at ~2GB. In case there is an issue with other components, memory consumption of the apiserver should not be that excessive. We just had the K8s cluster running and saw a permant increase in memory usage of the control plane nodes. And after some time (can not give a specific duration) the OS of the control plane node started to OOM kill processes. Let us know if you need additional information. <details</detailson-premise; control-planes are running with 4 CPU cores, 8GB of memory and and NVME discs <details</details<details</details<details</detailsNo response
/sig api-machinery
Please provide the pprof, and what is the size of your cluster.
As we were not sure if sharing the pprof is secure, we decided to only share screenshots first: ! ! From this information we found the this which pointed us to the mentioned feature flag. We sometimes see etcd connection timeouts in the apiserver logs, maybe this could be related but should not cause this behaviour. 5 control planes ~100 worker nodes ~1700 Pods
Can you provide the pprof without , so could compare the two?
Sure, the current pprof with set: ! !
cc
I believe this is Sounds like we may need to backport some of the dependency bumps
/assign
/sig instrumentation
/triage accepted (as it's now assigned to
/triage accepted
We need to apply the workaround in It should be simple, but needs to be backported to 1.27
all versions starting 1.27 right ?
Thanks for taking care of this so quickly
yes. All versions starting 1.27.
Actually, this only needs to be backported to v1.29.

At 1.28, we were using v0.35.0 of otelgrpc, which did not include metrics at the time.
Cherry-picks:
Change:
CurrentReplicas:                 currentReplicas, DesiredReplicas:                 desiredReplicas, CurrentCPUUtilizationPercentage: currentUtilization, <ins> LastScaleTime:                   hpa.Status.LastScaleTime, </ins> } if rescale { now := unversioned.NewTime(now)

Discussion:
Horizontal pod autoscaler makes decision to scale down after 1 minute from the previous scale down, although downscaleForbiddenWindow is 5 minutes. This causes flakiness of hpa e2e tests with stability checks:
CC
Found root cause: HPA was incorrectly resetting last scale time during status update when there was no rescale.
CC
Change:
for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { mockType.SecondClosestCommentLines = tt.tagComments <del> gotTag, gotMajor, gotMinor, err := extractKubeVersionTag(tt.tagName, mockType) </del> <ins> gotTag, gotMajor, gotMinor, err, fatalErr := safeExtractKubeVersionTag(tt.tagName, mockType) if (fatalErr != nil) != tt.wantFatal { t.Errorf("extractKubeVersionTag() fatalErr = %v, wantFatal %v", fatalErr, tt.wantFatal) return } if tt.wantFatal { return } </ins> if (err != nil) != tt.wantErr { t.Errorf("extractKubeVersionTag() error = %v, wantErr %v", err, tt.wantErr) return

Discussion:
The commands under will benefit of a batter unit test coverage as seen in Originally posted by in
/sig api-machinery /assign
GitHub didn't allow me to assign the following users: damiansawicki. Note that only with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /sig api-machinery 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
/triage accepted
Hi I would like to work on this issue. Could you tell me how many test files are needed per PR under this issue?
Hi the issue is already assigned to me. Would you consider contributing to other issues to avoid duplication?
Hi do you mind if I work on this issue along with you? I would only like to write tests on limited number of files, if that's okay with you...
Hi thanks for your engagement! If you also want to work on this particular issue, we should coordinate. Are you working on something other than ?
Hey currently I'm thinking of shifting to Do let me know if you are already working on that particular directory. Also I could assist you in any of your work on this issue as I'm not preoccupied at the moment.
Change:
"STANDARD_NV12_PROMO":    48, "STANDARD_NV12S_V2":      24, "STANDARD_NV12S_V3":      12, <ins> "STANDARD_NV16AS_V4":     32, </ins> "STANDARD_NV24":          64, "STANDARD_NV24_PROMO":    64, "STANDARD_NV24S_V2":      32, "STANDARD_NV24S_V3":      24, <ins> "STANDARD_NV32AS_V4":     32, </ins> "STANDARD_NV48S_V3":      32, <ins> "STANDARD_NV4AS_V4":      8, </ins> "STANDARD_NV6":           24, "STANDARD_NV6_PROMO":     24, "STANDARD_NV6S_V2":       12, <ins> "STANDARD_NV8AS_V4":      16, </ins> "STANDARD_PB6S":          12, }

Discussion:
<!-- Please only use this template for submitting enhancement requests -- What would you like to be : related to Why is this needed: /assign /sig azure
here is the way about how to get MaxDataDiskCount: and then build kubelet, copy kubelet to agent node and then get MaxDataDiskCount data: There are 207 VM sizes totally.
Update: this command could get VM size list easily:
Change:
"topology.kubernetes.io/zone":              "us-west-1a", "my.custom.label/foo":                      "fizz", "my.custom.label/bar":                      "foo", <ins> "app.k8snio/bar":                           "foo", "k8snio/bar":                               "foo", </ins> }, }, Spec: v1.NodeSpec{

Discussion:
For cloud provider nodes, there are some k8s label names are reserved. Like and The current regex is: This will match the dot . as any single character. This block adding a label name like: app.k8snio/name The regex format is incorrect, we should escape the dot in regex so that it can match the dot as a string. Can add additional label with name like: app.k8snio/name Configure AdditionalLabels in the instanceMeta to add additional label name with app.k8snio/name. No response <detailsClient Version: v1.30.1 Kustomize Version: v5.0.4-0.- Server Version: v1.30.0 </details<details</details<details</details<details</details<details</details<details</details
/sig cloud-provider
If it make sense to fix it, i would like to take it and raise a PR. /assign
Which Kubernetes component has the bug ? (eg: kubelet) Can you explain how to reproduce the problem?
It's the node controller in the shared library Though I really don't think cloud providers should be setting node labels like "", this is technically incorrect. This restriction is only applied to labels the cloud provider controller binary running this controller would attempt to add itself.
just noticed this after our SIG meeting today, cc
/triage accepted
please go ahead and raise a PR, thanks for reporting this =)
When fixing this, consider if there are any labels that cloud provider integration might legitimately set. For example: (documented as being set by cloud provider integration code). Some labels are OK to set; we could allowlist and explicitly. When rejecting some others, maybe setting a Condition on the Node ( perhaps) would help surface what's not right. Not sure. Making the simple fix is also fine by me.
OK. Thanks I have raised a PR for this: Not sure if this change looks good.
Change:
var DNS952LabelErrorMsg string = fmt.Sprintf(`must be a DNS 952 label (at most %d characters, matching regex %s): e.g. "my-name"`, validation.DNS952LabelMaxLength, validation.DNS952LabelFmt) var pdPartitionErrorMsg string = InclusiveRangeErrorMsg(1, 255) var PortRangeErrorMsg string = InclusiveRangeErrorMsg(1, 65535) <ins> var IdRangeErrorMsg string = InclusiveRangeErrorMsg(0, math.MaxInt32) </ins> var PortNameErrorMsg string = fmt.Sprintf(`must be an IANA_SVC_NAME (at most 15 characters, matching regex %s, it must contain at least one letter [a-z], and hyphens cannot be adjacent to other hyphens): e.g. "http"`, validation.IdentifierNoHyphensBeginEndFmt) const totalAnnotationSizeLimitB int = 256 * (1 << 10) // 256 kB

Discussion:
Help review this, thanks.
Are you asking for better validation on pod creation? I'm not really sure what you mean when you say "tip".
Yes, I mean it's better validate the pod when create. The tip mean the validation info response from server and show by client.
Change:
"net" "github.com/golang/glog" <ins> kubeoptions "k8s.io/kubernetes/pkg/kubeapiserver/options" </ins> "k8s.io/kubernetes/pkg/registry/core/service/ipallocator" )

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: There is currently no easy way to know what Kubernetes is using as the default CIDR for service cluster IPs. What you expected to happen: should be able to tell users that "10.0.0.0/24" is used as the default. They'd better check if their deployment environment has a conflict with this assumption. They need to customize this parameter to avoid such overlaps if any. How to reproduce it (as minimally and precisely as possible): Run , from the help, the default value for --service-cluster-ip-range is not mentioned. Anything else we need to know?: No. Environment: Kubernetes version (use ): Any Cloud provider or hardware configuration**: Any OS (e.g. from /etc/os-release): Any Kernel (e.g. ): Any Install tools: N/A Others: N/A
/sig api-machinery
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Change:
kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" "k8s.io/kubernetes/pkg/kubelet/nodestatus" "k8s.io/kubernetes/pkg/kubelet/util/sliceutils" <ins> kubeletvolume "k8s.io/kubernetes/pkg/kubelet/volumemanager" </ins> schedulerapi "k8s.io/kubernetes/pkg/scheduler/api" taintutil "k8s.io/kubernetes/pkg/util/taints" "k8s.io/kubernetes/pkg/version"

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] CSI Volumes [Driver: csi-hostpath-v0] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is gracefully deleted while kubelet is down [Disruptive][Slow] [sig-storage] CSI Volumes [Driver: csi-hostpath] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is gracefully deleted while kubelet is down [Disruptive][Slow] [sig-storage] CSI Volumes [Driver: ][Serial] [Testpattern: Dynamic PV (default fs)] subPath should unmount if pod is gracefully deleted while kubelet is down [Disruptive][Slow] Since when has it been failing: 2019-01-15 (when they were ) Testgrid link: Reason for failure: They all seem to be failing with: The failures seem to start with .
/sig storage
Summoning and This seems to have been failing since it was in master-blocking.
This is the same as
Thanks closing this one. /close
Closing this issue. <detailsIn response to : Thanks closing this one. 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
/reopen I took a look at the latest test failures and I think it is a different issue than
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
Looking at one test failure here: Sequence of events: stopped, pod deleted: started again: volume to dsw started and failed because it's not in the node's volumesinuse list. This repeats for a while. also started, but we skipped cleaning up because the volume is in dsw so we want to let volume manager gracefully cleanup don't remove volume from dsw because actual state has not been updated? So it seems like there's a problem with populating the node's volumesinuse after a kubelet restart.
cc
/assign will continue investigating.

i will try repro-ing at without different commits to try to figure out which pr introduced the regression
/priority important-soon
I ran these tests against a cluster with the NodeLease feature disabled, and the tests pass. So I think the issue is related to the new NodeLease feature enabled a month ago: cc
I discussed with VolumesInUse is updated periodically in the Node.Status. So we need to make sure this flow is working well with the NodeLease feature.
and I walked through the code. The NodeLease feature introduced an early exit to the node status update function, so our theory is we need to add a call to . I will make the change and test it out
Change:
}, nil } <del> func getThresholdEvents(eventfd int, eventCh chan<- int) { </del> <ins> func getThresholdEvents(eventfd int, eventCh chan<- struct{}, stopCh <-chan struct{}) { </ins> for { buf := make([]byte, 8) _, err := syscall.Read(eventfd, buf) if err != nil { return } <del> eventCh <- 0 </del> <ins> select { case eventCh <- struct{}{}: case <-stopCh: return } </ins> } } func (n *memcgThresholdNotifier) Start(stopCh <-chan struct{}) { <del> eventCh := make(chan int, 1) go getThresholdEvents(n.eventfd, eventCh) </del> <ins> eventCh := make(chan struct{}) go getThresholdEvents(n.eventfd, eventCh, stopCh) </ins> for { select { case <-stopCh:

Discussion:
close it may make kubelet crash, though the possibility is small. keep it open is just ok. And to avoid getThresholdEvents blocked for ever, stopCh should be passed in it.
Thanks for the PR!
Change:
} else if line[0] == ':' && len(line) > 1 { // We assume that the <line> contains space - chain lines have 3 fields, // space delimited. If there is no space, this line will panic. <del> chain := Chain(line[1:bytes.Index(line, spaceBytes)]) </del> <ins> spaceIndex := bytes.Index(line, spaceBytes) if spaceIndex == -1 { panic(fmt.Sprintf("Unexpected chain line in iptables-save output: %v", string(line))) } chain := Chain(line[1:spaceIndex]) </ins> chainsMap[chain] = line } }

Discussion:
On some systems, iptables-save outputs the following warning to stderr: Note that the error message includes a newline. Because kube-proxy captures both stdout and stderr when calling , the newline might cause rules to be garbled. For example, the output might contain the following line: The parser treats this as a chain line, and panics, as predicted in
/sig network
FYI
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
Just FYI here's another example of garbled output:
Anyway, fix is in Please review.
/assign
/remove-triage unresolved
Change:
cmdArgs = append(cmdArgs, "--kubeconfig", kubeconfigPath, "--root-dir", KubeletRootDirectory, <del> "--docker-disable-shared-pid=false", </del> "--v", LOG_VERBOSITY_LEVEL, "--logtostderr", "--allow-privileged", "true", )

Discussion:
Once the API for is finalized, add a node e2e test. /kind feature /assign /cc /sig node
We plan on adding this for 1.10
Change:
framework.ExpectNoError(err, "failed to get pod %s", pod.Name) ginkgo.By("Reading file content from the nginx-container") <del> resultString, err = framework.LookForStringInFile(f.Namespace.Name, pod.Name, busyBoxMainContainerName, busyBoxMainVolumeFilePath, message, 30*time.Second) framework.ExpectNoError(err, "failed to match expected string %s with %s", message, resultString) </del> <ins> result := f.ExecShellInContainer(pod.Name, busyBoxMainContainerName, fmt.Sprintf("cat %s", busyBoxMainVolumeFilePath)) framework.ExpectEqual(result, message, "failed to match expected string %s with %s", message, resultString) </ins> }) })

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-node-kubelet-orphans Which test(s) are failing: [sig-storage] EmptyDir volumes [It] pod should support shared volumes between containers [Conformance] Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know:
please don't CC sig-testing on every test failure :( we own the infrastructure etc. the sig-storage owns these tests.