jiebi/CodeConvo huggingface dataset:
Change:
fs.StringVar(&f.RootDirectory, "root-dir", f.RootDirectory, "Directory path for managing kubelet files (volume mounts,etc).") fs.Var(&f.DynamicConfigDir, "dynamic-config-dir", "The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. Presently, you must also enable the DynamicKubeletConfig feature gate to pass this flag.") <del> fs.Var(&f.InitConfigDir, "init-config-dir", "The Kubelet will look in this directory for the init configuration. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Omit this argument to use the built-in default configuration values. Presently, you must also enable the DynamicKubeletConfig feature gate to pass this flag.") </del> <ins> fs.Var(&f.InitConfigDir, "init-config-dir", "The Kubelet will look in this directory for the init configuration. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Omit this argument to use the built-in default configuration values. Presently, you must also enable the KubeletConfigFile feature gate to pass this flag.") </ins> // EXPERIMENTAL FLAGS fs.StringVar(&f.ExperimentalMounterPath, "experimental-mounter-path", f.ExperimentalMounterPath, "[Experimental] Path of mounter binary. Leave empty to use the default mount.")

Discussion:
See:
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-testing, kubernetes/test-infra and/or . /lifecycle stale
For some reason GitHub didn't close this automatically when the referencing PR merged.
Change:
}, { name:  "supported IPv6 cidr", <del> cidr:  "2001:db8::/98", addrs: 1073741824, </del> <ins> cidr:  "2001:db8::/48", addrs: 65536, </ins> }, { name:  "unsupported IPv6 mask", <del> cidr:  "2001:db8::/65", </del> <ins> cidr:  "2001:db8::/1", </ins> addrs: 0, }, }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When creating an IPv6 cluster, the --pod-network-cidr needs to be a /66, it cannot be for a larger network (smaller value) What you expected to happen: Should be able to use values smaller then /66, /64 or a /48 How to reproduce it (as minimally and precisely as possible): Create a cluster with Kubeadm, and set the podSubnet as below networking: podSubnet: "fd00:1:2:3::/64" 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: /area ipv6 /sig network
/assign rpothier
Change:
creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults <del> name: system:aws-cloud-provider roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:aws-cloud-provider subjects: - kind: ServiceAccount name: aws-cloud-provider namespace: kube-system - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults </del> name: system:basic-user roleRef: apiGroup: rbac.authorization.k8s.io

Discussion:
As of , all Kubernetes clusters with RBAC bootstrap roles for AWS, regardless of whether they are running on AWS. The hardcoded RBAC bootstrap policy should only include roles that are used by all clusters, regardless of addons, configuration, or cloud provider. The ClusterRole(Binding)s should be removed from the bootstrap policy, and instead configured by the provisioning tools. /sig aws /sig cloud-provider /sig auth
/assign I can help do it. :)
Change:
return err } <del> printObj, err := o.ToPrinter("drained") if err != nil { return err } </del> drainedNodes := sets.NewString() var fatal error for _, info := range o.nodeInfos { if err := o.deleteOrEvictPodsSimple(info); err == nil { drainedNodes.Insert(info.Name) <ins> printObj, err := o.ToPrinter("drained") if err != nil { return err } </ins> printObj(info.Object, o.Out) } else { if o.drainer.IgnoreErrors && len(o.nodeInfos) > 1 {

Discussion:
When draining a node, using kubectl drain [NODE], the output resembles this: Expected output should indicate that the node was drained, for example: kubectl drain [NODE] No response <details</details<detailsCan reproduce locally using and printing the output </details<details</details<details</details<details</details<details</details
/sig cli
/triage accepted
Change:
expectedNodeCondition := v1.NodeMemoryPressure expectedStarvedResource := v1.ResourceMemory pressureTimeout := 10 * time.Minute <ins> highPriorityClassName := f.BaseName + "-high-priority" highPriority := int32(999999999) BeforeEach(func() { _, err := f.ClientSet.SchedulingV1beta1().PriorityClasses().Create(&schedulerapi.PriorityClass{ObjectMeta: metav1.ObjectMeta{Name: highPriorityClassName}, Value: highPriority}) Expect(err == nil || errors.IsAlreadyExists(err)).To(BeTrue()) }) AfterEach(func() { err := f.ClientSet.SchedulingV1beta1().PriorityClasses().Delete(highPriorityClassName, &metav1.DeleteOptions{}) Expect(err).NotTo(HaveOccurred()) }) </ins> Context(fmt.Sprintf(testContextFmt, expectedNodeCondition), func() { tempSetCurrentKubeletConfig(f, func(initialConfig *kubeletconfig.KubeletConfiguration) { initialConfig.FeatureGates[string(features.PodPriority)] = true

Discussion:
https://k8s- The following tests are broken: NVIDIA GPU Device Plugin PriorityLocalStorageEvictionOrdering PriorityMemoryEvictionOrdering Looks like some new validation was to prevent two things: PodPriority directly system-critical priority classes outside of the kube-system namespace. To fix this, we need to create new priority classes for these tests. cc /kind failing-test /sig node /sig scheduling /priority important-soon
/kind bug
/assign
This doesn't appear to have fixed the tests. Tests now panic during the Aftereach in which the PriorityClass is deleted. /reopen
Panic:
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-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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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
Change:
if err != nil { return err } <del> status = kl.generatePodStatus(pod, s) </del> <ins> status = kl.generateAPIPodStatus(pod, s) </ins> } if status.Phase == api.PodRunning { possibleCIDRs.Insert(fmt.Sprintf("%s/32", status.PodIP))

Discussion:
We moved reason cache and status convert function from to by , , and . After this, we should also migrate related old unit test to kubelet level. For we should add test for: [x] Different image pull policy. [x] Pod creation failure. [x] Pod image failure. For we should add test for: [x] ContainerStatuses order. [x] Last termination state. [x] How reason cache will affect the PodPhase: [x] Pull image failure reason [x] Pod creation failure reason
Time to close this issue? :)
Not yet, The last 3 tests are in . :)
Change:
checks = []HealthzChecker{PingHealthz} } <del> glog.V(5).Info("Installing healthz checkers:", strings.Join(checkerNames(checks...), ", ")) </del> <ins> glog.V(5).Info("Installing healthz checkers:", formatQuoted(checkerNames(checks...)...)) </ins> mux.Handle(path, handleRootHealthz(checks...)) for _, check := range checks {

Discussion:
What happened: The logic in the checkerNames test for is faulty. Failing the test when the 'wanted' value equals the actual result is the opposite behavior of what we want. What you expected to happen: I expect the test to fail when the desired output is not the same as the actual output. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig api-machinery /assign
Change:
CRI_TOOLS_VERSION = "1.16.1" _CRI_TARBALL_ARCH_SHA256 = { <del> "amd64": "19fed421710fccfe58f5573383bb137c19438a9056355556f1a15da8d23b3ad1", "arm": "367826f3eb06c4d923f3174d23141ddacef9ffcb0c902502bd922dbad86d08dd", "arm64": "62b60ab7046b788df892a1b746bd602c520a59c38232febc0580692c9805f641", "ppc64le": "d6464188a5011242b8dad22cb1e55d8cb29d6873f3d1f3f3c32bb236d3fca64e", "s390x": "f3d5e707810d7985f6a470ea439ca5989c0ee218a824795ed1726f4958281a2d", </del> <ins> "linux-386": "35b721a7a90a12cf9689fb1f4fe5b50f73520200130a52b552234bd798d2ae9f", "linux-amd64": "19fed421710fccfe58f5573383bb137c19438a9056355556f1a15da8d23b3ad1", "linux-arm": "367826f3eb06c4d923f3174d23141ddacef9ffcb0c902502bd922dbad86d08dd", "linux-arm64": "62b60ab7046b788df892a1b746bd602c520a59c38232febc0580692c9805f641", "linux-ppc64le": "d6464188a5011242b8dad22cb1e55d8cb29d6873f3d1f3f3c32bb236d3fca64e", "linux-s390x": "f3d5e707810d7985f6a470ea439ca5989c0ee218a824795ed1726f4958281a2d", "windows-386": "b7564675f69aa2a01b092874c9c9aeda084204384d711a6fb85c6d2328ca5c7d", "windows-amd64": "7d092dcb3b1af2edf75477d5d049a70e8c0d1ac8242b1dff2de7e6aa084e3615", </ins> } ETCD_VERSION = "3.3.15"

Discussion:
Right now cri-tools only include tarballs for linux /cc /cc
/sig release
/area release-eng /milestone v1.16 /help /priority important-soon
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /area release-eng /milestone v1.16 /help /priority important-soon 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
Hello! I'm a bug triage shadow for the 1.16 release cycle and considering this issue is tagged for 1.16, I'd like to check its status. Code freeze is starting on August 29th (about 2 days from now). Do we still target this issue to be fixed for 1.16?
No, nobody is working on this for 1.16. cc
/milestone clear
anything we can do in release team to move this forward?
I'm working on this one now if nobody else minds. :) /assign
Change:
// +listType=atomic Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"` // HostAliases is an optional list of hosts and IPs that will be injected into the pod's hosts <del> // file if specified. This is only valid for non-hostNetwork pods. </del> <ins> // file if specified. </ins> // +optional // +patchMergeKey=ip // +patchStrategy=merge

Discussion:
there is a note above hostAliases that this feature does not work with hostNework=true, yet it seems it does: when testing with a hostNetwork pod + hostAliases, there are no errors in kubelet logs at --v=10 related to this, in fact i don't see any hostAlias entries at all in there. i could not find anything blocking this in the kubelet, in fact there is normal handling of hostNetwork: i could not find any validation performed on the hostAliases field of PodSpec if hostNetwork is true on the API level. i could not find any unit tests or e2e tests related to this. the godoc should contain valid information if the feature is not supposed to work, it must be patched to not have the entries in the hosts file (perhaps?) we should have tests that ensure this type of requirement is guaranteed these steps confirm that a static pod with hostNework (deployed by kubeadm) does make use of hostAliases. create a kubeadm single node cluster directly with or one with modify the to include:wait some time for the new static pod spec to resync find the PID of the kube-apiserverget the hosts file n/a latest master 1.30.0-alpha.0 not applicable <details</detailskubeadm containerd v1.6.14 kindnet add test: update godoc:
/sig node network cluster-lifecycle /kind documentation
as reported by the hostAliases sometimes are not mounted for hostNetwork static pods, which is concerning: related slack thread:
At minimum the comment is wrong I need to be updated and we need e2e tests :/
found this, support was a while back: i will PR the API docs.
We identified an edge case here with Kubernetes v1.29. If a cloud provider did not yet initialise the node's , the code for creating the file including the hostAliases does not get run. To be concrete, in: is empty in this case which leads to to be . I was able to trace it back to this change which leads to this behaviour for static pods: For confirmation: I reverted the above commit, rebuilt kubelet and it got back to the old behaviour.

there is no perfect solution, but reverting is wrong because opens another bug, we need to study this more carefully but in the meantime installers that know the nodes addresses beforehand should set the --node-ip flag or not use cloud-provider external
yeah, as i mentioned downstream, revering is out of the question. it fixes some long standing problems. we might have to document somewhere this limitation in a cloud provider env.
i think it might be possible for us to special case this so that the hostAlias management does not wait for the node IP in a CP env, under certain conditions. just a speculation.
PRs add test: update godoc:
/triage accepted looks like it is being worked on already
Change:
if err != nil { return err } <del> if len(externalIPs) > 0 { for _, externalIP := range externalIPs { err = testReachabilityOverExternalIP(externalIP, servicePort, pod) if err != nil { return err } } } </del> } return nil }

Discussion:
Which jobs are failing: Which test(s) are failing: - Since when has it been failing: Testgrid link: Reason for failure: Nov 4 11:59:41.385: Unexpected error: &lt;*errors.errorString | 0xc00298c3d0: { s: "service is not reachable within 2m0s timeout on endpoint 203.0.113.250:80 over TCP protocol", } service is not reachable within 2m0s timeout on endpoint 203.0.113.250:80 over TCP protocol occurred Anything else we need to know: /priority important-soon /sig network /cc
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
Apparently this is related to /cc
if you're busy and want me to take a look tomorrow you can assign that to me and I can deep dive into what's missing/happening :) Happy to help and to understand better the flakiness life
so, the test adds a "fake" external IP that should be nated to the service endpoint It went through the CI, you can check the test here passing more details in the issue I opened explaining the test
ok, this is interesting the test is failing when using container runtime DOCKER https://k8s- the same periodic job that uses container runtime CONTAINERD (same as the PR) is working https://k8s- We need to understand what is different regarding the network in GCE jbos, when using docker as runtime, kubenet??? cc:
one diff between the working jobs with containerd and the failing ones with docker is that the failing ones use this part of the code for reference, kube-proxy adds the NAT rules here for external IPs here
IIRC you are using kubenet for azure jobs, are you using docker as runtime, can you please check if this tests fails there too?
The problem happens on environment that are using the bridge plugin, seems I got wrong the feature will revert until we have the right test.

We use kubenet only for IPv6 and dualstack jobs. Rest of the tests use Azure CNI. Default is docker runtime for all jobs.
Change:
<ins> // +build !windows /* Copyright 2015 Google Inc. All rights reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package exec import "syscall" const X_OK = 0x1 func isExecutable(path string) bool { return syscall.Access(path, X_OK) == nil } </ins>

Discussion:
/priority critical-urgent /priority failing-test /kind bug /status approved-for-milestone This test has been failing since 2017-11-22 in which is on the , and prevents us from cutting [v1.9.0-beta.1] (kubernetes/sig-release). Is there work ongoing to bring this job back to green? https://k8s- first bad: https://k8s- this is also failing on (non-release-blocking) triage cluster suspect commit range:
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/remove-area platform/gke bad copy-pasta
This is a new test that was for a 1.9 alpha feature but actually exposed a bug with a different 1.8 alpha feature. Some discussion in . Since this seems to be a bug introduced in 1.8, I'm not sure if it needs to block 1.9. cc
Change:
return err } <ins> // apply volume ownership if !c.readOnly && fsGroup != nil { err := volume.SetVolumeOwnership(c, fsGroup) if err != nil { // attempt to rollback mount. glog.Error(log("mounter.SetupAt failed to set fsgroup volume ownership for [%s]: %v", c.volumeID, err)) glog.V(4).Info(log("mounter.SetupAt attempting to unpublish volume %s due to previous error", c.volumeID)) if unpubErr := csi.NodeUnpublishVolume(ctx, c.volumeID, dir); unpubErr != nil { glog.Error(log( "mounter.SetupAt failed to unpublish volume [%s]: %v (caused by previous NodePublish error: %v)", c.volumeID, unpubErr, err, )) return fmt.Errorf("%v (caused by %v)", unpubErr, err) } if unmountErr := removeMountDir(c.plugin, dir); unmountErr != nil { glog.Error(log( "mounter.SetupAt failed to clean mount dir [%s]: %v (caused by previous NodePublish error: %v)", dir, unmountErr, err, )) return fmt.Errorf("%v (caused by %v)", unmountErr, err) } return err } glog.V(4).Info(log("mounter.SetupAt sets fsGroup to [%d] for %s", *fsGroup, c.volumeID)) } </ins> glog.V(4).Infof(log("mounter.SetUp successfully requested NodePublish [%s]", dir)) return nil }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When a volume for a CSI-based PV being mounted, the code does not apply the fsGroup value when the PV is marked as readOnly = false. What you expected to happen: if pv.readOnly == false, then the fsGroup ownership value should be applied to the mounted volume.
/assign /sig storage
Change:
volumeMounts: - name: influxdb-persistent-storage mountPath: /data <del> - image: gcr.io/google_containers/heapster_grafana:v2.1.1 </del> <ins> - image: gcr.io/google_containers/heapster_grafana:v2.6.0-2 </ins> name: grafana env: resources:

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --- gce-os-master-alpha-features kubernetes.Up 05.2021 log- & in this test are deprecated starting with this the tests are failing therefore I'm also pinging
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
Kubelet log:
It seems to be related with . /cc I read the context: fixed pull-kubernetes-e2e-gce-alpha-features job failure for PR . gce-os-master-alpha-features need a similar change.
I tried to fix it in
the PR seems to solved it, thank you!
Change:
defer lb.lock.Unlock() state, exists := lb.services[svcPort] <del> if !exists { </del> <ins> if !exists || state == nil { </ins> return } for ip, affinity := range state.affinity.affinityMap {

Discussion:
As suggested in , some portions of the code contains the map checking for nil values in map, and others don't have. Even though we're never assigning nil values to this map, we should standardize the portions that does not have this check in module. Example: Should be like this: I can take care of this issue.
/sig network
There have been discussions of deprecating the user-space proxier. Maybe transfer it to . A question is if anybody still uses it. Seems like you do, so if possible please explain if you have a use-case where the user-space proxier is wanted/needed.
Hey Actually, I was casually reading the source code and I saw a over there regarding the nil checks. Regarding your question, we should check if anyone actually uses it though, or maybe discuss its usage or deprecation a little further.
Quick question though: I saw in the news that the user-space proxy porting was near completion, maybe it's worth talking to them in order to check upon the status.
I don't object to making it clearer or more consistent, if you want to spend time on it, but it's not a high priority. That said, I think a nil value in that map would be really bad (and should be impossible) and I don't know how we would raise a signal about it.
let us know if you want to try to fix it, otherwise we can just close this.
I already opened a PR with the clearer nil checks for this specific module in , so you can review it. I think whether this would have nil values into the service map we should discuss this apart and try to reproduce this case (if any would happen).
PR submitted, so let's review and discuss further there. /assign dcbw /triage accepted