jiebi/CodeConvo huggingface dataset:
Code change:
func TestHexCIDR(t *testing.T) { tests := []struct { <ins> name      string </ins> input     string output    string expectErr bool }{ { <del> input:  "1.2.0.0/16", </del> <ins> name:   "IPv4 masked", input:  "1.2.3.4/16", </ins> output: "01020000/ffff0000", }, { <ins> name:   "IPv4 host", </ins> input:  "172.17.0.2/32", output: "ac110002/ffffffff", }, { <ins> name:   "IPv6 masked", input:  "2001:dead:beef::cafe/64", output: "2001deadbeef00000000000000000000/ffffffffffffffff0000000000000000", }, { name:   "IPv6 host", input:  "2001::5/128", output: "20010000000000000000000000000005/ffffffffffffffffffffffffffffffff", }, { name:      "invalid CIDR", </ins> input:     "foo", expectErr: true, },

Related discussion:
text: Appears that it is expecting to reverse hex back to string, but test is not showing case of mask being properly applied. For example, "2001::5/64" when converted to hex and then back to string will be "2001::/64". Will update test to be more accurate.
/area networking
These labels do not exist in this repository: . <detailsIn response to : /area networking 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. I understand the commands that are listed . </details
/sig network
One question I have... Can the callers (bandwidth?) of the function work with an IPv6 based hex CIDR? In the future, if we support pod IPs that are IPv6 addresses, and we modify the code to add /128 vs /32, as is done currently, this would create an IPv6 based hex CIDR.
The only caller is currently the ingress/egress shaping function in kubelet. That code also needs to be updated for IPv6. For example, assumes IPv4 when adding CIDRs to the shaper list.
Agree.I wanted to separate this out, partly to make the change smaller, but also, when I looked at the callers (this shaping functionality) I wasn't sure if it would support IPv6. I looked a bit at the "tc" command and saw some notes that indicate that it doesn't support IPv6 yet. Is that still accurate? Would it be ok to tackle that separately?
Code change:
Spec:       v1.NodeSpec{}, Status: v1.NodeStatus{ Capacity: v1.ResourceList{ <del> v1.ResourceCPU:     *resource.NewMilliQuantity(2000, resource.DecimalSI), v1.ResourceMemory:  *resource.NewQuantity(10E9, resource.BinarySI), v1.ResourceStorage: *resource.NewQuantity(500*mb, resource.BinarySI), v1.ResourcePods:    *resource.NewQuantity(0, resource.DecimalSI), </del> <ins> v1.ResourceCPU:    *resource.NewMilliQuantity(2000, resource.DecimalSI), v1.ResourceMemory: *resource.NewQuantity(10E9, resource.BinarySI), v1.ResourcePods:   *resource.NewQuantity(0, resource.DecimalSI), </ins> }, Allocatable: v1.ResourceList{ <del> v1.ResourceCPU:     *resource.NewMilliQuantity(0, resource.DecimalSI), v1.ResourceMemory:  *resource.NewQuantity(10E9, resource.BinarySI), v1.ResourceStorage: *resource.NewQuantity(500*mb, resource.BinarySI), v1.ResourcePods:    *resource.NewQuantity(0, resource.DecimalSI), </del> <ins> v1.ResourceCPU:    *resource.NewMilliQuantity(0, resource.DecimalSI), v1.ResourceMemory: *resource.NewQuantity(10E9, resource.BinarySI), v1.ResourcePods:   *resource.NewQuantity(0, resource.DecimalSI), </ins> }, }, }

Related discussion:
text: Local storage is not expected to be available as a scheduling resource in v1.7. Kubelet is incorrectly exposing a resource named . This is incorrect because the feature is alpha and so it requires opt-in via feature flags and, the resource names are invalid. The expected resource names are listed - and . cc This is v1.7 blocker because we cannot expose a new resource in the API and rename it in a subsequent release.
CC I'll find someone on the storage team to address this.
/assign
GitHub didn't allow me to assign the following users: verult. Note that only can be assigned. <detailsIn response to : /assign 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
Code change:
fsInfo, err := p.cadvisor.GetDirFsInfo(mountpoint) if err != nil { msg := "Failed to get the info of the filesystem with mountpoint" <del> if err == cadvisorfs.ErrNoSuchDevice { </del> <ins> if errors.Is(err, cadvisorfs.ErrNoSuchDevice) || errors.Is(err, cadvisorfs.ErrDeviceNotInPartitionsMap) || errors.Is(err, cadvisormemory.ErrDataNotFound) { </ins> klog.V(2).InfoS(msg, "mountpoint", mountpoint, "err", err) } else { klog.ErrorS(err, msg, "mountpoint", mountpoint)

Related discussion:
text: What happened: New overlay filesystems created for Pods after kubelet start trigger repeated error messages. For example: Error messages are logged every 10 seconds for every filesystem created after kubelet start. For large kubelet nodes, this issue creates an excessive amount of error logs. What you expected to happen: New overlay filesystems created for Pods after kubelet start should not log error messages. How to reproduce it (as minimally and precisely as possible): Use cristatsprovider with cri-o and configure overlay storage. UsingLegacyCadvisorStats() needs to return false per for cristatsprovider to be used. Start with an empty /var/lib/containers/storage and schedule Pods on the node. Anything else we need to know?: As part of , cadvisor.GetFsInfoByFsUUID() was changed to cadvisor.GetDirFsInfo() in getFsInfo(); however, the test for cadvisorfs.ErrNoSuchDevice was not modified, changing how getFsInfo() handles a cache miss from cadvisor. cadvisor caches UUIDs/partitions/mounts on kubelet start and the cache is never refreshed. Given that it's expected that getFsInfo() will fail to retrieve data from cadvisor (see comments in ImageFsStats() and ), this condition should not be logged as an error. Alternatively, cadvisor fs could be modified to refresh on cache miss enabling getFsInfo() to return data on these filesystems. Environment: Kubernetes version (use ): 1.18.6 CRI: CRI-O
/sig node cc
ptal
thanks for reporting the issue. I will take a look at in upcoming week.
/assign
Sorry this is taking slightly longer. Currently held up in something little urgent, but as soon as that's over I will look into this one.
Do you have the time to look at this issue ? I can help with testing / debugging if required. Environment Kubernetes 1.19.3 Cri-o 1.19.0
Sorry I haven't gotten a chance to look into it yet, I would certainly appreciate any help in debugging. Thanks.
Right now I am thinking of either handling the cache miss better, or returning the even if the fs type is not in cadvisor, or both.
Issues go stale after 90d of inactivity. Mark the issue as fresh with .
Code change:
fsInfo, err := p.cadvisor.GetDirFsInfo(mountpoint) if err != nil { msg := "Failed to get the info of the filesystem with mountpoint" <del> if err == cadvisorfs.ErrNoSuchDevice { </del> <ins> if errors.Is(err, cadvisorfs.ErrNoSuchDevice) || errors.Is(err, cadvisorfs.ErrDeviceNotInPartitionsMap) || errors.Is(err, cadvisormemory.ErrDataNotFound) { </ins> klog.V(2).InfoS(msg, "mountpoint", mountpoint, "err", err) } else { klog.ErrorS(err, msg, "mountpoint", mountpoint)

Related discussion:
text: 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
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-contributor-experience at . /lifecycle rotten
kindly ping - has this already been implemented ?
/assign
Fix for k/k in and cadvisor in
/remove-lifecycle rotten
hi do you know when the fixes will be released ? Thanks!
I don't, unfortunately.
the fix has made it into , so I imagine the change will come in by 1.22
/triage accepted /priority important-soon
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
So v1.22 is out for a while now. Is there someone who has already upgraded to v1.22 and can confirm that the getFsInfo errors are fixed?
haircommander mentioned that the fix made it into cadvisor 0.40.0-rc.1. But cadvisor version bump did not happen in k8s yet, probably due to issues mentioned here: iirc kind did not work with image kindest/node v1.22.1, I did not look into logs however. Will update post once I have access to the affected device. Edit:
I still have these logs with version 1.22.2
I have got the same error log about kubelet kubernetes version 1.22.2 containerd: 1.4.11 Is this problem have been resolve?
Code change:
fsInfo, err := p.cadvisor.GetDirFsInfo(mountpoint) if err != nil { msg := "Failed to get the info of the filesystem with mountpoint" <del> if err == cadvisorfs.ErrNoSuchDevice { </del> <ins> if errors.Is(err, cadvisorfs.ErrNoSuchDevice) || errors.Is(err, cadvisorfs.ErrDeviceNotInPartitionsMap) || errors.Is(err, cadvisormemory.ErrDataNotFound) { </ins> klog.V(2).InfoS(msg, "mountpoint", mountpoint, "err", err) } else { klog.ErrorS(err, msg, "mountpoint", mountpoint)

Related discussion:
text: 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]:
I still have these logs with version 1.23.1
turns out we ended up being blocked on , so the fix has yet to be merged. let's push for it in 1.24
I'll wait for 1.24. With 1.22.5 My cluster has some of these messages but is stable. But with 1.23.x I get disk pressure because my sys logs get spammed quickly. I hoped going away fomr cadvisor to CRI stats woudl help, but instead of stat errors I now have these FS errors.
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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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.
Code change:
fsInfo, err := p.cadvisor.GetDirFsInfo(mountpoint) if err != nil { msg := "Failed to get the info of the filesystem with mountpoint" <del> if err == cadvisorfs.ErrNoSuchDevice { </del> <ins> if errors.Is(err, cadvisorfs.ErrNoSuchDevice) || errors.Is(err, cadvisorfs.ErrDeviceNotInPartitionsMap) || errors.Is(err, cadvisormemory.ErrDataNotFound) { </ins> klog.V(2).InfoS(msg, "mountpoint", mountpoint, "err", err) } else { klog.ErrorS(err, msg, "mountpoint", mountpoint)

Related discussion:
text: </details
This is still relevant and requires a fix with
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 Related PR still not merged.
SnoozeThis is useful if we don't want to keep polling until that PR is closed.
() I will wait until is merged and then add a comment.
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]:
Hi folks, I still have this issue in most recent Kubernetes 1.24.6. cAdvisor 0.44.0 that fix went into that version, is now a long time ago already in 1.24.0. Dep bump to runc 1.1.0, cadvisor 0.44.0 Automated cherry pick of : Bump cAdvisor to v0.44.1 28.4.2022 So is there possibly any chance to progress with a review of this PR please?
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
Code change:
fsInfo, err := p.cadvisor.GetDirFsInfo(mountpoint) if err != nil { msg := "Failed to get the info of the filesystem with mountpoint" <del> if err == cadvisorfs.ErrNoSuchDevice { </del> <ins> if errors.Is(err, cadvisorfs.ErrNoSuchDevice) || errors.Is(err, cadvisorfs.ErrDeviceNotInPartitionsMap) || errors.Is(err, cadvisormemory.ErrDataNotFound) { </ins> klog.V(2).InfoS(msg, "mountpoint", mountpoint, "err", err) } else { klog.ErrorS(err, msg, "mountpoint", mountpoint)

Related discussion:
text: 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 stale
Can we have any news on that topic please?
/remove-lifecycle rotten
This issue is labeled with but has not been updated in over 90 days, and should be re-triaged. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release. You can: Confirm that this issue is still relevant with (org members only) Deprioritize it with or Close this issue with For more details on the triage process, see /remove-triage accepted
Resolved.
Code change:
return err } <del> proxyBytes, err := kubeadmutil.MarshalToYamlForCodecsWithShift(cfg.KubeProxy.Config, kubeproxyconfigv1alpha1.SchemeGroupVersion, </del> <ins> proxyBytes, err := kubeadmutil.MarshalToYamlForCodecs(cfg.KubeProxy.Config, kubeproxyconfigv1alpha1.SchemeGroupVersion, </ins> kubeproxyconfigscheme.Codecs) if err != nil { return fmt.Errorf("error when marshaling: %v", err) } <ins> var prefixBytes bytes.Buffer apiclient.PrintBytesWithLinePrefix(&prefixBytes, proxyBytes, "    ") </ins> var proxyConfigMapBytes, proxyDaemonSetBytes []byte proxyConfigMapBytes, err = kubeadmutil.ParseTemplate(KubeProxyConfigMap19, struct {

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: MarshalToYamlForCodecs adds an indent to the yaml output. This code can be combined with PrintBytesWithLinePrefix What you expected to happen: 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): Kernel (e.g. ): Install tools: Others:
/assign rpothier
/sig cluster-lifecycle
/priority important-soon
Code change:
"k8s.io/utils/pointer" ) <ins> func init() { utilruntime.Must(metricsfeatures.AddFeatureGates(utilfeature.DefaultMutableFeatureGate)) } </ins> // proxyRun defines the interface to run a specified ProxyServer type proxyRun interface { Run() error

Related discussion:
text: As per, , wire up metrics/slis for kube-proxy
/assign
/sig network /sig instrumentation
This sounds OK, but we need to translate it into real work-to-do - volunteers? /triage accepted
is tackling this one :)
Code change:
"", }, { <del> "a test case with valid tags [LinuxOnly] [NodeConformance] [Serial]", </del> <ins> "a test case with valid tags [LinuxOnly] [NodeConformance] [Serial] [Disruptive]", </ins> "", }, {

Related discussion:
text: What would you like to be : Our tooling that makes the list of conformance tests needs to allow conformance tests to be marked as disruptive. Why is this needed: To test default, conformance behavior which may be disruptive (e.g. taint eviction) ref /sig testing /area conformance
Code change:
"", }, { <del> "a test case with valid tags [LinuxOnly] [NodeConformance] [Serial]", </del> <ins> "a test case with valid tags [LinuxOnly] [NodeConformance] [Serial] [Disruptive]", </ins> "", }, {

Related discussion:
text: What happened: Ran a conformance test run (using Sonobuoy) on One of the taint based tests a NoExecute taint to a node which evicted all workloads including the Sonobuoy workload itself. If this had been a prod workload, numerous prod workloads could have been impacted. What you expected to happen: Test run as normal with reasonable results. Able to run conformance tests with minimal impact on a running cluster. How to reproduce it (as minimally and precisely as possible): on a v1.16.0 cluster. Anything else we need to know?: Environment: Kubernetes version (use ): /area conformance
/sig testing /sig architecture /sig scheduling
Summarizing the many conversations on the PR and in Slack regarding this: We wish we had identified the lack of a tag sooner and could have taken better action. Since the release is 2 days away and our own tooling currently prohibits us from marking tests as both and , we've decided to let the release proceed with this "bug". Risk: Someone running the conformance tests may unexpectedly have their workloads evicted Mitigation: Sonobuoy v0.16.0 will provide the capabilities to the user to run a "conformance-lite" (name TBD) run if they'd like to run the conformance tests against a cluster with prod workloads. This way end-users can still be reasonably sure of their cluster's continued well-being. This mode will manually skip the tests in question until they can be more appropriately marked as Sonobuoy will also provide, consistent with past behavior, the means to run the full conformance suite including these disruptive tests. Eventual solution: Sonobuoy will, most likely, need to continue offering a "non-disruptive-conformance" mode to aid in end user testing but the regexp will change and should be able to just skip tests K8s tooling needs to be tweaked to allow for tests to be marked as The tag should be to these tests.
Code change:
api "k8s.io/kubernetes/pkg/apis/core" "k8s.io/kubernetes/pkg/features" "k8s.io/kubernetes/pkg/kubelet/client" <ins> utilpointer "k8s.io/utils/pointer" </ins> // ensure types are installed _ "k8s.io/kubernetes/pkg/apis/core/install"

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Some k8s client tried to evict a pod by setting negative value for deletionGracePeriodSeconds. But all eventual delete calls (and force-delete calls) made by kubelet, pod-garbage-collector, etc were not able to delete that pod, because apiserver doesnt allow deletionGracePeriodSeconds to be increased once it is set. So force-delete (which set it to 0) doesn't take effect when it's already negative. Not even kubectl is able to call delete with negative grace-period. But curl with an even more negative grace-period value worked. What you expected to happen: force-delete works. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: I think the issue is in the code below As the comment suggest, in phase 1, the was set to a negative value (meaning was in the past), and in phase 2, has to be set even lower, otherwise, it will be considered as pending graceful deletion and not performing the immediate delete. I think there're two possible fixes. not allowing setting in the past ( should be non-negative). In that case, we could convert to 0 if negative. that could be set in the past. In that case, in phase 2, we treat negative value of the same as 0, and allow immediate delete. Thoughts? 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:
/sig api-machinery
The label(s) cannot be applied, because the repository doesn't have them <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
/assign
/cc /triage accepted
No component in the system should ever treat the timestamp of DeletionTimestamp as authoritative.