jiebi/CodeConvo huggingface dataset:
Change:
RuntimeCgroupsName    string SystemCgroupsName     string KubeletCgroupsName    string <ins> KubeletOOMScoreAdj    int32 </ins> ContainerRuntime      string CgroupsPerQOS         bool CgroupRoot            string

Discussion:
runs in a container. Talos sets OOM score to -450 for the kubelet container and passes in the kubelet config. End result is that OOM score adj is -999 though. should have configured OOM score . Source code analysis. First, OOM score is set correctly from the config (flags): But then, in container manager, OOM score is reset to -999 via the following: This function should skip action if the PID is not running on the host: But the function looks to be confusing: When kubelet runs in a container with PID namespace shared with the host, kubelet's PID namespace will be equal to PID 1 namespace. If kubelet runs in a container with unshared PID namespace, kubelet's PID is 1 and its PID namespace is identical to PID 1 namespace. So how this function can return ever? Moreover, function is always setting OOM score to a hardcoded constant -999 ignoring configuation (). No response <details, reproduced with 1.22. </details<details</details<details</details<details</details<details</details<details</details
/sig node
/triage accepted
/assign
I don't think this method needs to change... I have make a draft PR for the default value to use the flag if present, but I would like more time to add some testing. Maybe you can have a look: ?
Thanks, this PR looks good to me, as it's going to set the OOM score to the configured value. And in our case kubelet runs in a container (not on the host, with proper OOM score via OCI spec), so this code should be even skipped, not sure how this can be addressed.
neither do I...
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
Change:
"testing" ) <del> func TestLoopbackHostPort(t *testing.T) { </del> <ins> func TestLoopbackHostPortIPv4(t *testing.T) { _, ipv6only, err := isIPv6LoopbackSupported() if err != nil { t.Fatalf("fail to enumerate network interface, %s", err) } if ipv6only { t.Fatalf("no ipv4 loopback interface") } </ins> host, port, err := LoopbackHostPort("1.2.3.4:443") if err != nil { t.Fatalf("unexpected error: %v", err)

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: LoopbackHostPort code is calling the which depends on the machine on which this test is running. Especially in this particular testase it looks for the ipv6 ip address which does not exist because the machine is not configured for ipv6. Because of the LoopbackHostPort function bahaves based on the interfaces configured, test will fail if machine is not really configured with ipv6. Need to rewrite the testcase to handle such situation. What you expected to happen: Testcase should pass
/sig network
/cc
/triage unresolved I am a bot run by ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
} if unmanaged { if az.ipv6DualStackEnabled { <del> //TODO (khenidak) add support for unmanaged nodes when the feature reaches  beta </del> <ins> //TODO (khenidak) add support for unmanaged nodes when the feature reaches beta </ins> return fmt.Errorf("unmanaged nodes are not supported in dual stack mode") } klog.V(2).Infof("CreateRoute: omitting unmanaged node %q", kubeRoute.TargetNode)

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: Kubernetes shouldn't put route table when it's already been configured. Azure cloud provider should check whether the route has already been created before invoking . 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig cloud-provider /priority important-soon
Why this is a bug? A PUT operation should be idempotent and multiple calls should get the same result?
Right. But cloud provider shouldn't make unnecessary API calls.
To check whether it is configured, we need a GET call, so we're going to replace PUT call with GET call in this case?
it's not a replace, we need to LIST routes and check whether it has already been there, then PUT if it's not.
I got your point. But if we directly send a PUT request, seems route RP will also do this comparation? Is there any issue making us have to do the comparation by ourselves instead of sending PUT request to route RP?
It would help to reduce the chances of ARM PUT throttling.
I'd like to work on this
/assign
Change:
spc.setsIndexer.Add(set) ssc.enqueueStatefulSet(set) fakeWorker(ssc) <del> pods, err = spc.addTerminatedPod(set, ord) </del> <ins> pods, err = spc.addTerminatingPod(set, ord) </ins> pod = getPodAtOrdinal(pods, ord) ssc.updatePod(&prev, pod) fakeWorker(ssc)

Discussion:
/assign flakes in PR jobs more than once per day The can filter down to searching for results for a single test:
This test continues to flake PRs at least once per day:
https://k8s-
looking at it
Change:
"//pkg/api:go_default_library", "//pkg/apis/extensions:go_default_library", "//pkg/apis/extensions/validation:go_default_library", <ins> "//vendor:k8s.io/apimachinery/pkg/api/equality", </ins> "//vendor:k8s.io/apimachinery/pkg/fields", "//vendor:k8s.io/apimachinery/pkg/labels", "//vendor:k8s.io/apimachinery/pkg/runtime",

Discussion:
Kubernetes version (use ): Environment: Cloud provider or hardware configuration: DigitalOcean OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools:Others: What happened: when I do: it will run rolling update ONLY if there is a change. In case I do: Each time I run it - it will execute rolling update, which is misleading. What you expected to happen: I would like to have consistent behavior for Deployment and DaemonSet How to reproduce it (as minimally and precisely as possible): Create any DaemonSet with following:
Hmm, it shouldn't happen. TemplateGeneration is updated only when something changed. I will debug it.
I can reproduce this, and the DaemonSet is updated after every , even when nothing is changed. In , old/new DaemonSet template are seen as different with . I tried to change this part to use instead (needed to update code in validation as well), and the DaemonSet templates were then seen as the same, and thus the issue was gone. We used everywhere in the controllers. Is the right way to compare stuffs?
It's very strange. I tried to use pretty.Diff to print the differences but it returns empty slice. apiequality.Semantic.DeepEqual uses forked version of reflect.DeepEqual and it's little different from version in 1.7. will you prepare the patch?
The key of the reported DaemonSet config is its . Note that in the config file, (empty list); however, in the live DaemonSet object (created from the config file), (null list). That's why thinks they're different. If we use in the config file instead, won't change. From the field description, empty list and null list are different. Feel it's api machinery related
protobuf storage isn't able to store , so the object has that field set to when read back from storage. that is causing problems for that field in particular (where and have different meanings) see
cc for behavior of namespaces field
so it's not a DaemonSet bug
Well, still not sure whether Semantic.DeepEqual should be used or not. I'm still concerned with the behavior of the controller for other fields that can be populated with non-null empty lists by users, but serialize back out to null (or set omitempty)
deployments are using Maybe we should also switch?

If empty lists should be treated differently from null list, we should replace with in controller code.
that distinction is going away in all the fields I know of... I'm not super happy with Semantic.DeepEqual masking the difference between those two things, but that's probably the right thing for you to be using
Special meaning of [] was removed in I think a switch to Semantic.DeepEqual is still needed here
Filed
Change:
import ( "fmt" <ins> "strconv" </ins> "strings" "k8s.io/kubernetes/pkg/api/v1" netsets "k8s.io/kubernetes/pkg/util/net/sets" <ins> "github.com/golang/glog" </ins> ) const (

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: AWS m4.2xlarge OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4.4.0-36-generic Install tools: kubeadm Others: 1 master and 1 minion What happened: This states that if using kube-proxy will only proxy requests to local endpoints, never forwarding traffic to other nodes and thereby preserving the original source IP address. However when I annotate my NodePort type service with this annotation I see the following error in the logs of kube-proxy of the node where the only pod of the service is running: After this message the service stops working outside of the cluster on the specified NodePort. What you expected to happen: I expected to see that only the with the pod on it serves traffic. How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
Sorry, I have found the issue, I had a setup where the none of the node names were the same as the hostname of the kube-proxy pod and this caused the issue, where none of the Pods running on a hosts were recognised as local pods. I have fixed this issue by manually setting the hostname with in kube-proxy. However I still insist that this error message is misleading and shouldn't be printed in case of NodePort type services, but only for just LoadBalancers.
I met the same problem in the aws cloud providers, by adding - the hostname-override to solve this problem. good
Change:
}, }, }, <ins> { name:           "skipped prescore plugin number greater than the number of score plugins", plugins:        buildScoreConfigDefaultWeights(scorePlugin1), pluginConfigs:  nil, skippedPlugins: sets.New(scorePlugin1, "score-plugin-unknown"), want: []framework.NodePluginScores{ { Name:   "node1", Scores: []framework.PluginScore{}, }, { Name:   "node2", Scores: []framework.PluginScore{}, }, }, }, </ins> } for _, tt := range tests {

Discussion:
When initializing kube-scheduler, We provided a custom config file for KubeSchedulerConfiguration and disabled the score plugin. This resulted in a panic in kube-scheduler at kube-scheduler up and running Using the below KubeSchedulerConfiguration file to enable kube-scheduler. apiVersion: kind: KubeSchedulerConfiguration clientConnection: kubeconfig: profiles: plugins: score: disabled: name: '*' extenders: urlPrefix: https://127.0.0.1:/scheduler filterVerb: "predicates" weight: 1 httpTimeout: 60s enableHTTPS: true nodeCacheCapable: false ignorable: false While trying to debug the issue, I found a change done recently for preScore calculation which might be causing the issue When we disable only the Score plugin then scheduler configuration will result in default preScorePlugins with 3 enabled [NodeResourcesFit, InterPodAffinity, TaintToleration] And due to this change, the preScore for InterPodAffinity results in skip status for some case (still not able to figured out what exactly it is), and this might result in a panic for kube-scheduler. The numplugin variable turns out to be negative. 28.3 N/A No response kubeadm No response No response
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
Let me take a look.
/assign
maybe related to
Past me argued this in the PR
scheduler-plugins' integration test also hits this: To end-users: if the fix () or its cherrypicks are not around in your k8s cluster. The workaround is that when disabling Score plugins, ensure to disable their PreScore counterparts as well.
Change:
}, } <del> for _, tt := range tests { cache := newSchedulerCache(ttl, time.Second, nil) </del> <ins> for i, tt := range tests { t.Run(fmt.Sprintf("case_%d", i), func(t *testing.T) { cache := newSchedulerCache(ttl, time.Second, nil) </ins> <del> if err := tt.handler(cache, tt.pod); err != nil { t.Fatalf("unexpected err: %v", err) } </del> <ins> if err := tt.handler(cache, tt.pod); err != nil { t.Fatalf("unexpected err: %v", err) } </ins> <del> if !tt.assumePod { if err := cache.UpdatePod(tt.pod, tt.podToUpdate); err != nil { t.Fatalf("UpdatePod failed: %v", err) </del> <ins> if !tt.assumePod { if err := cache.UpdatePod(tt.pod, tt.podToUpdate); err != nil { t.Fatalf("UpdatePod failed: %v", err) } </ins> } <del> } cachedPod, err := cache.GetPod(tt.pod) if err != nil { t.Fatalf("GetPod failed: %v", err) } if !reflect.DeepEqual(tt.podToUpdate, cachedPod) { t.Fatalf("pod get=%s, want=%s", cachedPod, tt.podToUpdate) } </del> <ins> cachedPod, err := cache.GetPod(tt.pod) if err != nil { t.Fatalf("GetPod failed: %v", err) } if !reflect.DeepEqual(tt.podToUpdate, cachedPod) { t.Fatalf("pod get=%s, want=%s", cachedPod, tt.podToUpdate) } }) </ins> } }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently some unit tests in pkg/scheduler is not organized as Use subtests can make it easier to find out which case fails and leverage benefit of parallelism . Why is this needed: Follow Go test practice.
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
/remove-kind feature /kind cleanup /sig scheduling /assign
Change:
} os.MkdirAll(dir, 0750) <ins> // check whether it belongs to fuse, if not, default to use kernel mount. if cephfsVolume.checkFuseMount() { glog.V(4).Infof("CephFS fuse mount.") err = cephfsVolume.execFuseMount(dir) // cleanup no matter if fuse mount fail. keyringPath := cephfsVolume.GetKeyringPath() _, StatErr := os.Stat(keyringPath) if !os.IsNotExist(StatErr) { os.RemoveAll(keyringPath) } if err == nil { // cephfs fuse mount succeeded. return nil } else { // if cephfs fuse mount failed, fallback to kernel mount. glog.V(4).Infof("CephFS fuse mount failed: %v, fallback to kernel mount.", err) } } glog.V(4).Infof("CephFS kernel mount.") </ins> err = cephfsVolume.execMount(dir) <del> if err == nil { return nil </del> <ins> if err != nil { // cleanup upon failure. util.UnmountPath(dir, cephfsVolume.mounter) return err </ins> } <del> // cleanup upon failure util.UnmountPath(dir, cephfsVolume.mounter) // return error return err </del> <ins> return nil </ins> } type cephfsUnmounter struct {

Discussion:
The goal of this issue is to design a CephFS driver using FUSE client for Kubernetes.</brExisting Ceph kernel client has the following drawbacks:</br• Kernel client does not support client-enforced quotas. • Kernel CephFS doesn't support quota or capacity, capacity requested by PVC is not enforced or validated. • Kernel CephFS doesn't work with SELinux, setting SELinux label in Pod's security context will not work.
Just a detail. Since we will rely on ceph-fuse, we will need the ceph-fuse client to be available on all kubernetes nodes. We can add a parameter to allow the use of the kernel client as well. I would say better make the fuse client opt-in and keep the kernel one as the default option. The kernel client might support quotas in the future. Thanks
/sig storage
We are also inclined to use fuse instead of kernel client ,any progress on this issue?
I like to continue this job and prepare to send a PR to make kubernetes support cephfs fuse mounting.
/assign I think this task would be valuable. =)
waiting for the PR, do you have a plane to support s3 fuse ?
No, no plan for s3fs-fuse currently
also see and cc
Ceph-fuse support in the command to display the specified secret, it may take some time to support, because it involves LibFUSE(I will follow up this demand). On the other hand, ceph-fuse has stability, quota function, expansion, upgrade and other advantages. Although ceph-fuse only supports the secret file way, but if it can be pushed to the k8s community, there is a very meaningful thing.
Change:
} // Version returns the runtime name, runtime version and runtime API version <del> func (ds *dockerService) Version(apiVersion string) (*runtimeApi.VersionResponse, error) { </del> <ins> func (ds *dockerService) Version(_ string) (*runtimeApi.VersionResponse, error) { </ins> v, err := ds.client.Version() if err != nil { return nil, fmt.Errorf("docker: failed to get docker version: %v", err) } runtimeAPIVersion := kubeAPIVersion name := dockerRuntimeName <ins> // Docker API version (e.g., 1.23) is not semver compatible. Add a ".0" // suffix to remedy this. apiVersion := fmt.Sprintf("%s.0", v.APIVersion) </ins> return &runtimeApi.VersionResponse{ Version:           &runtimeAPIVersion, RuntimeName:       &name, RuntimeVersion:    &v.Version, <del> RuntimeApiVersion: &v.APIVersion, </del> <ins> RuntimeApiVersion: &apiVersion, </ins> }, nil }

Discussion:
umbrella issue: kuberuntime uses to ]parse the version string of the api version]() from the runtime. When using with docker, it complains that Maybe we should just enforce that the api version returned by the runtime should be semver compatible. /cc
This is mentioned in . :) For now, we can add a after the docker apiversion to make it semver compatible.
Thanks for the reminder! We should make it clear in the API. This blocks kubelet from starting up, so we should fix it first.
I've checked the code, currently is only used in when checking the docker version compatibility. It is not exposed to the user by any means, so it should be fine to make some change ourselves, such as adding a . However, if we want to expose this to the user via in the future, it may make user confusing.
Change:
number of Replicas. release: v1.19 file: test/e2e/scheduling/preemption.go <ins> - testname: Scheduler, Verify PriorityClass endpoints codename: '[sig-scheduling] SchedulerPreemption [Serial] PriorityClass endpoints verify PriorityClass endpoints can be operated with different HTTP methods [Conformance]' description: Verify that PriorityClass endpoints can be listed. When any mutable field is either patched or updated it MUST succeed. When any immutable field is either patched or updated it MUST fail. release: v1.20 file: test/e2e/scheduling/preemption.go </ins> - testname: Scheduler, Basic Preemption codename: '[sig-scheduling] SchedulerPreemption [Serial] validates basic preemption works [Conformance]'

Discussion:
The following PriorityClass endpoints was Promoted it 1.14 without Conformance tests, and remain untested: replace-, read-, patch-, list-, delete-collection- SchedulingV1PriorityClass According to this APIsnoop query, there are still some remaining PriorityClass endpoints which are untested. with this query you can filter untested endpoints by their category and eligiblity for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints ! createSchedulingV1PriorityClass deleteSchedulingV1PriorityClass Promoted to Conformance 1.19 with /sig testing /sig architecture /area conformance
Is the ultimiate goal to use conformance tests to explicitly issue all CRUD requests against PriorityClass? And, is equivalent to "update PriorityClass"?
all APIs must have Conformance tests unless they are not eligible for Conformance due to the There is other APIGroups that have both Replace and Update as endpoints. That is the prerogative of the SIG to decide.
can you please point us to similar conformance tests used for core objects such as pods and nodes?
This is a life cycle test for Create, List, Update, Patch, DeleteCollection More can be found in the test/e2e folder. Also look for examples on the Conformance at previously Promoted Conformance test Reach out if we can help with more information on our approach to Conformance testing.
I remembered about this PR. Last week a few lines of code was to cover the last of the "Lease" endpoint group for conformance. The one file contain the Conformance tests for the complete life cycle of Lease endpoints.
/assign I will work on it.
/reopen Will monitor in test grid to move to Conformance after 2 weeks soak.
Reopened this issue. <detailsIn response to : /reopen Will monitor in test grid to move to Conformance after 2 weeks soak. </details
/triage accepted
Change:
"reflect" "testing" <ins> "github.com/stretchr/testify/assert" </ins> "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/client-go/kubernetes/fake" utiltesting "k8s.io/client-go/util/testing" "k8s.io/kubernetes/pkg/util/mount"

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: We have pretty large clusters in aws and in production, we found an inefficiency in provisioning dynamic EBS volumes, where aws-ebs volume provisioner tries to look for available zone from aws directly. With scale, this can trigger massive from ec2, and affect cluster stability. This is also related to What you expected to happen: To simply get zones with available instances, we can get information from API server for efficiency. There might be a delay between node gets shutting down and such change is reflected in api server, but in case node is not ready or gets terminated, there will be higher level reconciliation triggered so we are safe. How to reproduce it (as minimally and precisely as possible): We only expect this to be hit when the cluster is huge (or aws account is huge) so not easy to reproduce. /assign /sig aws /sig cloud-provider
/assign