jiebi/CodeConvo huggingface dataset:
Code change:
command: - /bin/bash - -c <del> - /opt/kube-addons.sh 1>>/var/log/kube-addon-manager.log 2>&1 </del> <ins> - exec /opt/kube-addons.sh 1>>/var/log/kube-addon-manager.log 2>&1 </ins> resources: requests: cpu: 5m

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG <!-- 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 ): 3 Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: All of the salt scripts bundled in kubernetes (for example, ) start up the component in a broken way. They use which means the shell will intercept all signals. So these daemons are not gracefully shutdown when the pod is stopped. This causes serious problems since when apiserver is killed abruptly it doesn't seem to close watches correctly. This was observed in for example. What you expected to happen: Running is incorrect. It should run the binary directly. Otherwise, it needs to perform an so the binary correctly replaces the shell script process. How to reproduce it (as minimally and precisely as possible): Run kube-apiserver inside a container with and try to stop it. You can't - eventually docker will force kill it. Anything else we need to know:
It looks like we changed from running the binaries directly to using in (from a few years ago to enable us to capture logs. or may recall why we had to use a shell since they reviewed that PR.
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.
Code change:
command: - /bin/bash - -c <del> - /opt/kube-addons.sh 1>>/var/log/kube-addon-manager.log 2>&1 </del> <ins> - exec /opt/kube-addons.sh 1>>/var/log/kube-addon-manager.log 2>&1 </ins> resources: requests: cpu: 5m

Related discussion:
text: 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
/remove-lifecycle stale
Code change:
name                           string hostnameOverride               bool nodeIP                         net.IP <ins> secondaryNodeIP                net.IP </ins> cloudProviderType              cloudProviderType nodeAddresses                  []v1.NodeAddress expectedAddresses              []v1.NodeAddress

Related discussion:
text: When adding to kubelet and to the OpenStack external cloud provider, which is based on kubernetes v1.27.1, the node annotation only shows one address and consequently the node addresses also only displays one address. The kubelet logs shows that node-ip contains dual-stack addresses. The annotation on the node would contain both IPv4 and IPv6 addresses and the node addresses would list them. Deploy a cluster with to kubelet and external cloud provider. Also make sure the external cloud provider is based on Kubernetes 1.27. Kubelet logs: one of CCMs Pods: one of the nodes annotation: <details</details<details</details<details</details<details</details<details</details<details</details
/sig network /sig cloud-provider /cc
/assign
/triage accepted
Code change:
{ Image:   image.GetE2EImage(), Name:    "computer-name-test", <del> Command: []string{"cmd.exe", "/K", "IF", "NOT", "%COMPUTERNAME%", "==", targetNode.Name, "(", "exit", "-1", ")"}, </del> <ins> Command: []string{"powershell.exe", "-Command", command}, </ins> }, }, RestartPolicy: v1.RestartPolicyNever,

Related discussion:
text: Windows GCE jobs: [sig-windows] [Feature:WindowsHostProcessContainers] [MinimumKubeletVersion:1.22] HostProcess containers should run as a process on the host/node [sig-windows] [Feature:WindowsHostProcessContainers] [MinimumKubeletVersion:1.22] HostProcess containers should support various volume mount types Since the jobs were reintroduced. Windows COMPUTERNAMEs are typically limited to 15 characters [1], while the kubelet nodes spawned in the GCE test jobs are much longer (e.g.: `). The names might be truncated, resulting in the test failure. [1] No response /sig windows /sig testing
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
dupe of /close
Closing this issue. <detailsIn response to : dupe of /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
Code change:
{ Image:   image.GetE2EImage(), Name:    "computer-name-test", <del> Command: []string{"cmd.exe", "/K", "IF", "NOT", "%COMPUTERNAME%", "==", targetNode.Name, "(", "exit", "-1", ")"}, </del> <ins> Command: []string{"powershell.exe", "-Command", command}, </ins> }, }, RestartPolicy: v1.RestartPolicyNever,

Related discussion:
text: I want to run the e2e test but it failed. Reason: Node name and hostname is longer than 15 characters. But the ComputerName only used the first 15 characters. So they don't equal and the test failed. The e2etest should pass regardless of the hostname length. Deploy a Windows with long nodename (longer than 15 characters). Then, run e2e test. No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig testing
Can you show the error message?
STEP: Destroying namespace "host-process-test-windows-2574" for this suite. • Failure [6.334 seconds] [sig-windows] [Feature:WindowsHostProcessContainers] [Excluded:WindowsDocker] [MinimumKubeletVersion:1.22] HostProcess containers should run as a process on the host/node [It] Nov 21 22:12:49.003: Expected <v1.PodPhase: Failed to equal <v1.PodPhase: Succeeded {"msg":"FAILED [sig-windows] [Feature:WindowsHostProcessContainers] [Excluded:WindowsDocker] [MinimumKubeletVersion:1.22] HostProcess containers should run as a process on the host/node","total":1,"completed":0,"skipped":1147,"failed":1,"failures":["[sig-windows] [Feature:WindowsHostProcessContainers] [Excluded:WindowsDocker] [MinimumKubeletVersion:1.22] HostProcess containers should run as a process on the host/node"]}
/sig windows does this hostname error ring a bell?
We discussed this a bit on slack, the test is using %COMPUTERNAME% to validate we are running on the host. This value is truncated to 15 chars on windows due to netbios. We could use the hostname, which isn't truncated, with a fallback to computer name for this validation to make the test validate more scenarios. Important to note that some scenarios might not work if in older environments that use netbios but for our test purposes this will work. Long discussion on netbios here:
We'll be working on this as part of a broader windows operational readiness work. Thanks wenli for digging into it.
Code change:
{ Image:   image.GetE2EImage(), Name:    "computer-name-test", <del> Command: []string{"cmd.exe", "/K", "IF", "NOT", "%COMPUTERNAME%", "==", targetNode.Name, "(", "exit", "-1", ")"}, </del> <ins> Command: []string{"powershell.exe", "-Command", command}, </ins> }, }, RestartPolicy: v1.RestartPolicyNever,

Related discussion:
text: /assign
Just for broader context... the reason wenli discovered this is, bc we heavily test cluster API over here :), where the dynamically generated host name appends machine-set + cluster characters, so the machines have names like this: to the machines initial name, and it's hardcoded. We want to try to improve this upstream , and have a proposal to do this in flight also:
/sig windows /remove-sig testing
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
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.
Code change:
{ Image:   image.GetE2EImage(), Name:    "computer-name-test", <del> Command: []string{"cmd.exe", "/K", "IF", "NOT", "%COMPUTERNAME%", "==", targetNode.Name, "(", "exit", "-1", ")"}, </del> <ins> Command: []string{"powershell.exe", "-Command", command}, </ins> }, }, RestartPolicy: v1.RestartPolicyNever,

Related discussion:
text: 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. </details
/reopen being fixed by
Reopened this issue. <detailsIn response to : /reopen being fixed by 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
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
Code change:
{ Image:   image.GetE2EImage(), Name:    "computer-name-test", <del> Command: []string{"cmd.exe", "/K", "IF", "NOT", "%COMPUTERNAME%", "==", targetNode.Name, "(", "exit", "-1", ")"}, </del> <ins> Command: []string{"powershell.exe", "-Command", command}, </ins> }, }, RestartPolicy: v1.RestartPolicyNever,

Related discussion:
text: This bot triages issues 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 with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <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 with Mark this issue 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. </details
Code change:
FSType:       "ext4", }, }, <ins> AccessModes: []v1.PersistentVolumeAccessMode{v1.ReadOnlyMany}, </ins> }, }, false), root: tmpDir,

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When use ceph as storageclass, i set accessModes: ReadOnlyMany, and create pods using the claim, only one pod would be running and the others on different nodes would get stuck on ContainerCreating. But if the pods are all on same node, it works fine. What you expected to happen: Pods on different nodes can mount ceph rbd volume. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.9.2 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): 3.10.0-327.18.2.el7.x86_64 Kernel (e.g. ): CentOS Linux release 7.2.1511 (Core) Install tools: kubeadm Others:
/sig storage
/assign
, how would this work? For example, how do you put the initial contents of the RBD volume on it if it is in the ReadOnlyMany access mode? How would you use this feature? As a cheap way of sharing files across a Kubernetes cluster? I'm just interested. -ben england
Do we really want to support ? I have the same questions as mentioned above. If we set the PVC AccessMode to , then the field in will need to be set true ? If so, for the first time, in , we will mount the device without formatting, is that intended ? We need to format the device manually before we use it ? /cc FYI: also there is an issue related to this:
We have this same problem for GCE PD, which supports ReadOnlyMany. You need to mount the volume first as RWO, in order to format the filesystem and populate it with data (mounting a read only volume with no data on it seems pointless). Then you have to fully unmount/detach it, and then you can deploy pods using it as ROX. Basically, you can dynamically provision it in RWO to format + populate data. But afterwards, you need to manually create a different PV/PVC for ROX
continuation
Code change:
fs.MarkDeprecated("resource-container", "This feature will be removed in a later release.") fs.StringVar(&o.config.ClientConnection.Kubeconfig, "kubeconfig", o.config.ClientConnection.Kubeconfig, "Path to kubeconfig file with authorization information (the master location is set by the master flag).") fs.Var(utilflag.PortRangeVar{Val: &o.config.PortRange}, "proxy-port-range", "Range of host ports (beginPort-endPort, single port or beginPort+offset, inclusive) that may be consumed in order to proxy service traffic. If (unspecified, 0, or 0-0) then ports will be randomly chosen.") <del> fs.StringVar(&o.config.HostnameOverride, "hostname-override", o.config.HostnameOverride, "If non-empty, will use this string as identification instead of the actual hostname.") </del> <ins> fs.StringVar(&o.hostnameOverride, "hostname-override", o.hostnameOverride, "If non-empty, will use this string as identification instead of the actual hostname.") </ins> fs.Var(&o.config.Mode, "proxy-mode", "Which proxy mode to use: 'userspace' (older) or 'iptables' (faster) or 'ipvs' (experimental). If blank, use the best-available proxy (currently iptables).  If the iptables proxy is selected, regardless of how, but the system's kernel or iptables versions are insufficient, this always falls back to the userspace proxy.") fs.Int32Var(o.config.IPTables.MasqueradeBit, "iptables-masquerade-bit", utilpointer.Int32PtrDerefOr(o.config.IPTables.MasqueradeBit, 14), "If using the pure iptables proxy, the bit of the fwmark space to mark packets requiring SNAT with.  Must be within the range [0, 31].") fs.DurationVar(&o.config.IPTables.SyncPeriod.Duration, "iptables-sync-period", o.config.IPTables.SyncPeriod.Duration, "The maximum interval of how often iptables rules are refreshed (e.g. '5s', '1m', '2h22m').  Must be greater than 0.")

Related discussion:
text: Pods not getting scheduled on the new node joined to the cluster using kubespray The node joined to the cluster but new pods schedueld on the nodes are failing with error "get https://10.233.0.1 : dial tcp 10.233.0.1: 443 connection refused" Network plugin - calico kube-proxy running in ipvs mode new worker node, can connect to master server ip address over 6443 new worker node, cannot access cluster ip 10.233.0.1 over port 443 , nodelocaldns and kube-proxy pods are in running state on new node -proxy logs show error "invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP" Unable to write event: 'Post https://127.0.0.1:6443/api/v1/namespaces/default/events dial tcp 127.0.0.1:6443 connection refused" -ln output do not show any services addr show output do not show kube-ipvs0 and calico interfaces Can someone please help. Thanks
Code change:
driverName: driverName, } if shouldTimeout { <del> timeout := plugin.PluginClientTimeout + time.Millisecond </del> <ins> timeout := plugin.PluginClientTimeout + 10*time.Millisecond </ins> fakeDRADriverGRPCServer.timeout = &timeout }

Related discussion:
text: This flakiness is reproducible on x86 and ppc64le architectures. https://prow.ppc64le- in /sig
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 testing
/sig node /assign
Code change:
if !v.Served { continue } <del> // Defaults are not pruned here, but before being served. </del> spec, err := builder.BuildOpenAPIV2(crd, v.Name, builder.Options{V2: true}) <ins> // Defaults must be pruned here for CRDs to cleanly merge with the static // spec that already has defaults pruned spec.Definitions = handler.PruneDefaults(spec.Definitions) </ins> if err != nil { return nil, false, err }

Related discussion:
text: Noticed while reproducing with client-side validation: Steps to reproduce: published openapi only contains expected metadata definitions: a CRD, e.g. simple- at published openapi: where the _v2 definition is referenced: For some reason, the same server publishing openapi for built-in types and custom resource definitions thinks the openapi definition differs. Reproduced against at least the following branches: master release-1.23 release-1.22 release-1.21 In addition to fixing this to make coherently refer to ObjectMeta definitions from built-in and custom types, we need a test for this scenario to ensure it doesn't creep back in.
/sig api-machinery /priority important-longterm
cc - this is the sort of thing I was remembering which prompted the question about merging openapi internally () This needs to be resolved and test coverage improved here ahead of making v2-facing openapi changes
is there a rule that we can validate and enforce here? i.e. are there cases where it's normal to have two metadata? Probably in the case where an extension apiserver has a different version of kubernetes that has a slightly different metadata. I wish we could catch somehow that this doesn't happen.
In a server with no aggregated API servers, we should never have multiple definitions for ObjectMeta (CRDs and built-in types should reference the same ObjectMeta)
/triage accepted
/cc
This is fixed by on master. For 1.24, 1.23, 1.22 and 1.21, cherry picks have been created: 1.24: 1.23: 1.22: 1.21:
also need it on 1.24?
Updated the list above.
Code change:
cpu: "30m" # BEGIN_PROMETHEUS_TO_SD - name: prometheus-to-sd-exporter <del> image: k8s.gcr.io/prometheus-to-sd:v0.5.0 </del> <ins> image: gke.gcr.io/prometheus-to-sd:v0.11.1-gke.1 </ins> # Request and limit resources to get guaranteed QoS. resources: requests:

Related discussion:
text: the following images are using old client-go that would not work correctly starting 1.22+ if those images use in-cluster config(mounted service account token) to talk to kube-apiserver: if the above images use in-cluster config, they should use client-go 1.14+. xref: /assign /cc /sig instrumentation /priority important-soon
/triage accepted
Code change:
tests := []struct { new  core.Pod old  core.Pod <ins> opts PodValidationOptions </ins> err  string test string }{

Related discussion:
text: See for context. This issue is creating to track work on the API validation changes. Validation relaxation of certain fields in the pod spec to allow for mutable scheduling directives.
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
/assign
/sig scheduling
Docs PR:
Code change:
func(client kubeclientset.Interface, obj pkgruntime.Object) error { ingress := obj.(*extensionsv1beta1.Ingress) glog.V(4).Infof("Attempting to delete Ingress: %v", ingress) <del> err := client.Extensions().Ingresses(ingress.Namespace).Delete(ingress.Name, &metav1.DeleteOptions{}) </del> <ins> orphanDependents := false err := client.Extensions().Ingresses(ingress.Namespace).Delete(ingress.Name, &metav1.DeleteOptions{OrphanDependents: &orphanDependents}) </ins> return err })

Related discussion:
text: Problem: When users sends a cascading deletion request to federation i.e they set orphanDependents=false, then federation should also set orphanDependents=false, when it sends the request to underlying clusters.
Fixed by