jiebi/CodeConvo huggingface dataset:
Change:
}, }, }, <ins> "job does not allow setting status on create": { job: batch.Job{ ObjectMeta: getValidObjectMeta(0), Spec: batch.JobSpec{ Selector: validSelector, Template: validPodTemplateSpec, }, Status: batch.JobStatus{ Active: 1, }, }, wantJob: batch.Job{ ObjectMeta: getValidObjectMetaWithAnnotations(1, map[string]string{batchv1.JobTrackingFinalizer: ""}), Spec: batch.JobSpec{ Selector: validSelector, Template: validPodTemplateSpec, }, }, }, </ins> } for name, tc := range cases {

Discussion:
The gets very long testing mulitple functions in such as , and . These checks should be performed in dedicated Test functions using table for different scenarios. Target functions and are being as part of The remaining checks should be migrated to these functions. Also, a test function should be to migrate the remaining tests.
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 apps
/assign
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
Any progress on this? I'm working on and I noticed that has relatively low coverage so I was going to work on getting the coverage up.
I created that is somewhat related to this.
no progess. go ahead please
/assign
Change:
ret=1 fi <del> if ! _out="$(diff -Naupr -x "BUILD" -x "AUTHORS*" -x "CONTRIBUTORS*" vendor "${_kubetmp}/vendor")"; then </del> <ins> if ! _out="$(diff -Naupr -x "BUILD" -x "zz_generated.openapi.go" -x "AUTHORS*" -x "CONTRIBUTORS*" vendor "${_kubetmp}/vendor")"; then </ins> echo "Your vendored results are different:" >&2 echo "${_out}" >&2 echo "Godeps Verify failed." >&2

Discussion:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: 2019-03-07, in master, in 1.14 Testgrid link: /sig testing /priority critical-urgent /milestone v1.14 cc
/milestone v1.14
/remove-sig testing /sig api-machinery Related: , ,
cc It looks like this started failing right after this merge: (commit )
fix in
/reopen For CI Signal to verify that things look green once we got more job runs
Reopened this issue. <detailsIn response to : /reopen For CI Signal to verify that things look green once we got more job runs 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
All green :tada: /close
Closing this issue. <detailsIn response to : All green :tada: /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:
// Teardown cleans up any remaining resources. func (t *HPAUpgradeTest) Teardown(f *framework.Framework) { // rely on the namespace deletion to clean up everything <ins> common.DeleteHorizontalPodAutoscaler(t.rc, t.hpa.Name) </ins> t.rc.CleanUp() }

Discussion:
Currently the time it takes for HPA and CA to scale up after load increase is not measured at all, and this can lead to regressions that will be missed. This issue is about adding an e2e test that will prevent such regressions.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
Filip, can you reopen? I cannot do this myself, and this issue is clearly not closed yet.
Thanks Wojtek!
Change:
l := klog.Level(1) l.Set("1") // hijack the klog output <del> tmpWriteBuffer := bytes.NewBuffer(nil) </del> <ins> tmpWriteBuffer := new(buffer) </ins> klog.SetOutput(tmpWriteBuffer) klog.LogToStderr(false)

Discussion:
There seems to be a race condition in the following unit test The race happens between read at and write at No race condition CI logs where race was detected: <details</details<details</details<details</details<details</details<details</details<details</details
/sig node /cc
/remove-kind bug /kind flake (potential flake, did not use the flake template because CI is green for this test)
A related pr merged
/assign
Thanks for checking again. fyi
Maybe we need something like this:
are u working on resolve this issue? i wonder why doesn't face a race condition
I think he's still working on it. The race condition doesn't happen there because doesn't start another go routine. In the kubelet's case however, the write part of the race condition happens in another go routine that is spawned: write:
/triage accepted /priority important-soon
seen in this spiked in the last couple days - is this related to the klog bump ()? cc /priority critical-urgent /milestone v1.24
increasing priority since it is impacting test runs, and marking as blocker until root caused and we understand whether it is prod-impacting
/assign ^ I'll take this one up on monday - still feel free to open a PR if you have WIP investigation/research
please see if you have comments/inputs on the already open one.
I don't see how the klog bump could have made it worse. Perhaps the change around the flush daemon changed some timing conditions, but that's a rather wild guess. These tests have been faulty all along and need to be fixed. What klog can do is support unit tests like this better. I've opened two issues: short term: long term as it depends on contextual logging:
I think it's safe to remove the release-blocker here. The root cause is largely as explained here: (appears to be test-only)
Change:
JumpChain: "ACCEPT", MatchSet: kubeHealthCheckNodePortSet, }}, string(kubeServicesChain): {{ <ins> JumpChain: "RETURN", SourceAddress: "127.0.0.0/8", }, { </ins> JumpChain: string(kubeMarkMasqChain), MatchSet: kubeClusterIPSet, }, { JumpChain: string(kubeNodePortChain), MatchSet: "",

Discussion:
Loopback addresses (127.0.0.0/8, ::1/128) can't be used by services in proxy-mode=ipvs it makes sense to dismiss those early, add RETURN rule to KUBE-NODE-PORT,KUBE-SERVICES No response <details</details25 <details</detailsnone <details</details<details</details<details</details<details</details
/sig network
As mentioned in , this is not a bug since the nodeport and ephemeral ranges overlap.
/kind cleanup /kind remove-bug
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /kind cleanup /kind remove-bug </details
/remove-kind bug
The title of this issue should be changed to something like; Which would indicate that this is not a bug fix but an improvement. Also remove the invalid use-case in the description and add references to comments in like I think to dismiss nodePort connects to localhost early for proxy-mode=ipvs is an improvement, and in the majority of systems traffic to localhost is more common than traffic to nodePorts so this change will also improve overall performance. This is not a fix for overlapping ephemeral and nodePort ranges! So if the title and description is not updated the correct triage is to close this issue as it violates the non overlapping rule for ephemeral/nodeport ranges, please see
/area ipvs
Ok, i will change issue title and descripiton
/triage accepted
Change:
func (p *Plugin) InspectFeatureGates(featureGates featuregate.FeatureGate) { p.expansionRecoveryEnabled = featureGates.Enabled(features.RecoverVolumeExpansionFailure) p.dynamicResourceAllocationEnabled = featureGates.Enabled(features.DynamicResourceAllocation) <del> p.kubeletCSRAdmissionValidationDisabled = featureGates.Enabled(features.DisableKubeletCSRAdmissionValidation) </del> <ins> p.allowInsecureKubeletCertificateSigningRequests = featureGates.Enabled(features.AllowInsecureKubeletCertificateSigningRequests) </ins> } // SetExternalKubeInformerFactory registers an informer factory into Plugin

Discussion:
This comes from We've a feature gate, . However, we try to name feature gates after the positive thing they add, even if it's on by default, or even if we're setting if false because the positive thing is being dropped (rare, but it happens). Typically we don't start feature gate names with , as it makes the docs jar: Example quote 1: To temporarily revert to the legacy behavior, enable the feature gate. vs Example quote 2: You can enable the feature gate if you run code that relies on the previous behavior. You should plan to migrate. and because disabling things isn't really a feature. Some examples of gates you can or once could disable by turning them off_ include: - - - So, I recommend a rename of the gate before the v1.31 release. /sig auth architecture
FYI
Example gate names: (off by default) (off by default) (on by default) (on by default) (on by default) from (off by default, deprecated)
/milestone v1.31
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Milestone Maintainers Team and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone v1.31 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
Another possibility: , deprecated, off by default
Hello there! I am new to kubernetes and I want to contribute in it. Is it something that I can contribute to?
This issue is not a good issue for a first-time contributor to work on.
I'm a fan of , deprecated, off by default
hoping one of you are doing the PR? :) /milestone v1.31
Change:
before running <del> `kube init --config <path_to_configuration_file>` </del> <ins> `kubeadm init --config <path_to_configuration_file>` </ins> to specify the ipvs mode before deploying the cluster.

Discussion:
says: It likely means not , but
/sig network /good-first-issue Thanks! TODO: Change to
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig network /good-first-issue Thanks! 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
/unassign
/triage accepted
Change:
// of StartRecordingToSink. This lets you also process events in a custom way (e.g. in tests). // NOTE: events received on your eventHandler should be copied before being used. // TODO: figure out if this can be removed. <del> StartEventWatcher(eventHandler func(event runtime.Object)) func() </del> <ins> StartEventWatcher(eventHandler func(event runtime.Object)) (func(), error) </ins> // StartStructuredLogging starts sending events received from this EventBroadcaster to the structured // logging function. The return value can be ignored or used to stop recording, if desired.

Discussion:
Follow-up cleanup work for: Most of the information about this issue can be found in , where the work merged with a to change the function signature of to return a func() as well as an error. This issue will help to track that. All TODOs introduced in are resolved. N/A N/A <detailsN/A </details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority low 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
/cc /triage accepted
/priority important-longterm
/assign
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:
- piosz - jsafrane - jbeda <ins> vendor-reviewers: - thockin vendor-approvers: - thockin </ins>

Discussion:
/assign /cc Please ensure that every sub directory of / contains an owners file. The following sub directories do not define them: The result of this is that any PR which changes anything in api, Godeps, staging, vendor, etc will always get assigned to one of you for both the review and approval.
I recall someone also mentioning that certain files or dirs may not need approvers files. If that would help, we can add that functionality (i've already started the work)
staging and api should be easy to find owners for. may have ideas for translations. The big one is Godeps, third_party, vendor. Those are just grunt work. And figuring out criteria for approving is hard as they are a lot of code and it is unclear that things are tested well or automatically. (I'm thinking things like libraries for accessing cloud APIs). Having a dedicated team/process there might help.
I'll open some proposals for staging and API.
Godep in particular needs to be watched for things like licenses, which I have mostly been doing.
Thanks Clayton for the staging and api additions! How about if we pick two of you at random and shove them in as owners for each of the remaining directories?
What's left: translations: the kubectl specific translations is being handled by sig-cli, but the rest of the files like README and test have been handled and approved mostly by thirdparty: this is a tricky mix of stuff like forked code.. mostly handled by the likes of or for approvals. Godep/vendor: These could probably be solved by having a process to follow, and then delegating to a team in OWNERSALIASES for both folders.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Still relevant. /remove-lifecycle stale
Change:
} if s.BootstrapToken != nil { <del> fs.BoolVar(&s.BootstrapToken.Allow, "experimental-bootstrap-token-auth", s.BootstrapToken.Allow, ""+ </del> <ins> fs.BoolVar(&s.BootstrapToken.Enable, "experimental-bootstrap-token-auth", s.BootstrapToken.Enable, ""+ "Deprecated (use --enable-bootstrap-token-auth).") fs.MarkDeprecated("experimental-bootstrap-token-auth", "use --enable-bootstrap-token-auth instead.") fs.BoolVar(&s.BootstrapToken.Enable, "enable-bootstrap-token-auth", s.BootstrapToken.Enable, ""+ </ins> "Enable to allow secrets of type 'bootstrap.kubernetes.io/token' in the 'kube-system' "+ "namespace to be used for TLS bootstrapping authentication.") }

Discussion:
/kind feature As part of , the flag on the API server should be renamed to something like . We'll leave deprecated (should it be a no-op or not?) for v1.8. Or we should consider adding an explicit flag to the API server in the same way we have  flag on controller-manager. Right now, it enables/disables most authn plugins implicitely based on other flags (often pointing to various files on disk; if you specified a path to that file, you also want to enable this authn module) What way do you prefer?
/assign
Rough plan: (1.8) Add (1.8) Make it an error to specify both and (so we don't have to decide on precedence) (1.8) Add a warning if is used. (1.9) Drop
is: Mark deprecated. cc Approve?
/reopen Re-opening because there's a little bit left to do in 1.9 (ready to go in ).
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. If the required changes are not made within 6 days, the issue will be moved out of the v1.8 milestone. priority: Must specify exactly one of [, , ]. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Change:
fi fi cat > "${config_path}" <<EOF <ins> version = 2 # Kubernetes requires the cri plugin. required_plugins = ["io.containerd.grpc.v1.cri"] </ins> # Kubernetes doesn't use containerd restart manager. <del> disabled_plugins = ["restart"] </del> <ins> disabled_plugins = ["io.containerd.internal.v1.restart"] </ins> oom_score = -999 [debug] level = "${CONTAINERD_LOG_LEVEL:-"info"}" <del> [plugins.cri] </del> <ins> [plugins."io.containerd.grpc.v1.cri"] </ins> stream_server_address = "127.0.0.1" max_container_log_line_size = ${CONTAINERD_MAX_CONTAINER_LOG_LINE:-262144} <del> [plugins.cri.cni] </del> <ins> [plugins."io.containerd.grpc.v1.cri".cni] </ins> bin_dir = "${KUBE_HOME}/bin" conf_dir = "/etc/cni/net.d" conf_template = "${cni_template_path}" <del> [plugins.cri.registry.mirrors."docker.io"] </del> <ins> [plugins."io.containerd.grpc.v1.cri".containerd] default_runtime_name = "runc" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] runtime_type = "io.containerd.runc.v2" [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] </ins> endpoint = ["https://mirror.gcr.io","https://registry-1.docker.io"] EOF

Discussion:
Both jobs are failing with the same error message. pull-kubernetes-e2e-gce-ubuntu-containerd gce-ubuntu-master-containerd Tests are not run as clusters fail to come up. gce-ubuntu-master-containerd: Cluster creations failures started 2021/04/09 05:09 AM PST. pull-kubernetes-e2e-gce-ubuntu-containerd: Cluster creation failures started around 2021/04/08 3:15 AM PST Cluster creation script fails
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
I0410 20:45:23. ] "Receiving a new pod" pod="kube-system/etcd-server-e2e---master" I0410 20:45:23. ] "Receiving a new pod" pod="kube-system/kube-apiserver-e2e---master" I0410 20:45:23. ] "Receiving a new pod" pod="kube-system/kube-controller-manager-e2e---master" E0410 20:45:23. ] "Version from runtime service failed" err="rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService" E0410 20:45:23. ] "Get runtime version failed" err="get remote runtime typed version failed: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService" E0410 20:45:23. ] "Failed to run kubelet" err="failed to run Kubelet: failed to create kubelet: get remote runtime typed version failed: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService" kubelet.service: Main process exited, code=exited, status=1/FAILURE kubelet.service: Failed with result 'exit-code'.
Looks like infra-commit is related PR: /cc
fix is going in here
Change:
// This is a snapshot of expected options parsed by args. expected := &ServerRunOptions{ ServiceNodePortRange:   kubeoptions.DefaultServiceNodePortRange, <ins> ServiceClusterIPRange:  kubeoptions.DefaultServiceIPCIDR, </ins> MasterCount:            5, EndpointReconcilerType: string(reconcilers.MasterCountReconcilerType), AllowPrivileged:        false,

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: There is currently no easy way to know what Kubernetes is using as the default CIDR for service cluster IPs. What you expected to happen: should be able to tell users that "10.0.0.0/24" is used as the default. They'd better check if their deployment environment has a conflict with this assumption. They need to customize this parameter to avoid such overlaps if any. How to reproduce it (as minimally and precisely as possible): Run , from the help, the default value for --service-cluster-ip-range is not mentioned. Anything else we need to know?: No. Environment: Kubernetes version (use ): Any Cloud provider or hardware configuration**: Any OS (e.g. from /etc/os-release): Any Kernel (e.g. ): Any Install tools: N/A Others: N/A
/sig api-machinery
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Change:
vols, vErrs := ValidateVolumes(spec.Volumes, fldPath.Child("volumes")) allErrs = append(allErrs, vErrs...) <del> allErrs = append(allErrs, validateContainers(spec.Containers, vols, fldPath.Child("containers"))...) </del> <ins> allErrs = append(allErrs, validateContainers(spec.Containers, false, vols, fldPath.Child("containers"))...) </ins> allErrs = append(allErrs, validateInitContainers(spec.InitContainers, spec.Containers, vols, fldPath.Child("initContainers"))...) allErrs = append(allErrs, validateRestartPolicy(&spec.RestartPolicy, fldPath.Child("restartPolicy"))...) allErrs = append(allErrs, validateDNSPolicy(&spec.DNSPolicy, fldPath.Child("dnsPolicy"))...)

Discussion:
I found that kubelet will not allocate hostports specified from initContainers. And PodFitsHostPorts in kube-scheduler does not take initContainer into consideration. Also, kube-apiserver think such pod is illegal, but I think it OK. We should make the behavior of spec.HostPorts in initContainer clear
/sig node
Exactly. I think this makes sense. Since initContainers are expected to be completed, we should not expose extra port mappings during creating pod sandbox, which may bring in security risks.
Sounds good to me.
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
/remove-lifecycle stale