jiebi/CodeConvo huggingface dataset:
Change:
type PersistentVolumeList struct { TypeMeta `json:",inline"` <del> ListMeta `json:"metadata,omitempty"` </del> <ins> ListMeta `json:"metadata,omitempty" description:"standard list metadata; see http://docs.k8s.io/api-conventions.md#types-kinds` </ins> Items    []PersistentVolume `json:"items,omitempty" description:"list of persistent volumes"` } // PersistentVolumeClaim is a user's request for and claim to a persistent volume type PersistentVolumeClaim struct { TypeMeta   `json:",inline"` <del> ObjectMeta `json:"metadata,omitempty"` </del> <ins> ObjectMeta `json:"metadata,omitempty" description:"standard object metadata; see http://docs.k8s.io/api-conventions.md#metadata"` </ins> // Spec defines the volume requested by a pod author Spec PersistentVolumeClaimSpec `json:"spec,omitempty" description: "the desired characteristics of a volume"`

Discussion:
PR had a few errors in its API objects, where the "description" field errors in its JSON declarations were missing. But, the "verify-" presubmit check didn't flag them. This should be investigated and fixed.
Could you please take a look at this?
Change:
} t.Run(gvk.String(), func(t *testing.T) { <del> for i := 0; i < 50; i++ { </del> <ins> for i := 0; i < 3; i++ { </ins> item := fuzzObject(t, gvk) builder := applyconfigurations.ForKind(gvk) unstructuredRoundTripApplyConfiguration(t, item, builder)

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --pull-kubernetes-unit Two new tests were just in that take significant amounts of time in CI: ~These tests also appear to be flaking regularly: /assign
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
Related: At some point we should probably adjust the timeout. I'd like to get CI to a point where it uses whatever the default is in make test.
yes.
This loops each type 50 times, I'll drop that down to say, 3 times. We honestly don't need to fuzz these that hard, they typically catch problems quick.
The failures I see in gubernator shouldn't happen now that the PR is merged. Before myPR to add this test was merged, other PRs that fields (NamespaceSelector) would cause myPR's unit tests to fail and I would need to rebase it and run . Now that it is merged, will be run by the PR author that adds a field to a type to keep code in sync.
ah, so these failures on other PRs mean they needed to regen?
Yeah, the first one adds and the fuzzer detected the apply config builder had not been regenerated by . The others have field changes too.
ok, so it's noise for PRs in progress but not flakes. looks like the runtime/timeout issue is the only flake, which you can drop iterations significantly to solve
50-3 seems like it should get us to 10-15s total for both new tests
Change:
import ( "context" <ins> "math/rand" </ins> "reflect" "strings" "testing"

Discussion:
When updating policy labels on a namespace, existing pods are evaluated to see if they are compatible with the new policy. If there are too many pods, or if evaluation takes too long, we short circuit and warn that not all pods were checked. For that reason, we want to prioritize checking a variety of pods before checking essentially identical pods, so that unique warnings can be surfaced before reaching the pod count cutoff or evaluation timeout. Pods created by the same controller are most likely to be identical (e.g. replicas from a replicaset or job, copies of pods from a statefulset or daemonset, etc) cc
This is an interesting fix I'd like to take this up Can I take this up? I am fairly new to Kubernetes source code so might need some help
I am guessing this is where the logic you mentioned should be implemented right?
thanks for the interest; this is targeted at the beta version... right now, effort is going toward the alpha-blocking work for 1.22
Should I wait for the code freeze before working on this? Sorry for lame questions
If you want to start looking at it, that's fine, but it's possible the code in the ValidateNamespace function will change before we're ready to start merging 1.23 work, and there isn't really reviewer bandwidth to take a look at work-in-progress stuff for next release yet.
Sure, I'll just for code freeze before I start with implementation By the time I'll just assign this to myself /assign
Does it make sense to take it up now? I think we already have a couple of RC builds after the code freeze
sure, it's fine to start work in a branch in your fork and have a WIP PR open, even before master reopens for 1.23 work
Awesome, I'll start working on it Thank you
Hello! Are you still working on this? If you don't have time, I can take this issue. If not, maybe I can give some help
Since this was not an urgent issue I was working on some other issues last week I have started on this, Will be raising a PR maybe today or tomorrow I Will ask you if I get stuck Thank you
Change:
// getJobFromTemplate makes a Job from a CronJob func getJobFromTemplate(sj *batchv1beta1.CronJob, scheduledTime time.Time) (*batchv1.Job, error) { <del> // TODO: consider adding the following labels: // nominal-start-time=$RFC_3339_DATE_OF_INTENDED_START -- for user convenience // scheduled-job-name=$SJ_NAME -- for user convenience </del> labels := copyLabels(&sj.Spec.JobTemplate) annotations := copyAnnotations(&sj.Spec.JobTemplate) // We want job names for a given nominal start time to have a deterministic name to avoid the same job being created twice

Discussion:
What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "scheduledjob" (and try to understand from the title whether this could be related to my issue) "find job" Is this a BUG REPORT or FEATURE REQUEST? (choose one): Feature request. Kubernetes version (use ): ~ Environment: Cloud provider or hardware configuration: AWS via kube-aws 0.93-ish What happened: I'm using scheduled jobs, and then try to review the logs of the job executions. I have multiple scheduled jobs in the system. Generally this works via: ... search for the ones that seem to relate to my scheduled job name . Repeat this if there are more than one execution. the whole list for previous jobs What you expected to happen: I'd love to be able to filter the initial job list already to only include jobs created by a specific scheduled job, something like . For that to happen I need scheduledjob to label the created job, just like a job already labels the pods executing it.
can you include labels in the cronjob's jobTemplate spec?
Yes, that is certainly possible. I filed this ticket mainly because I think this should happen automatically: Any resource produced by a resource I created should be labeled such that I can find these resources back easily.
/sig apps
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
From my perspective this is still something I'd like to see.
I've given this a go. There was actually a todo for it in the comments.
/remove-lifecycle rotten
Lovely, thanks a lot!
Change:
<del> # Copyright (C) 2017 SUSE LLC. All rights reserved. # Use of this source code is governed by a BSD-style # license that can be found in the LICENSE file. language: go go: - 1.13.x - 1.16.x - tip arch: - AMD64 - ppc64le os: - linux - osx script: - go test -cover -v ./... notifications: email: false </del>

Discussion:
One of the dependencies of k8s, filepath-securejoin, has a following vulnerability discovered: It has been patched in version 0.2.4, however k8s is still using version 0.2.3. Potential fix: updating the dependency. A small PR will follow. /sig security
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 security
/kind bug /sig security
Change:
hostConfig.SecurityOpt = append(hostConfig.SecurityOpt, "no-new-privileges") } <del> hostConfig.MaskedPaths = sc.MaskedPaths hostConfig.ReadonlyPaths = sc.ReadonlyPaths </del> <ins> if !hostConfig.Privileged { hostConfig.MaskedPaths = sc.MaskedPaths hostConfig.ReadonlyPaths = sc.ReadonlyPaths } </ins> return nil }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: kind bug What happened: After execute kubeadm init during kube-proxy pod initialization there is CrashLoopBackOff error all the time Logs from pod: [centos ~]$ kubectl logs kube-proxy-8gs45 -n kube-system What you expected to happen: kube-proxy pod run properly How to reproduce it (as minimally and precisely as possible): follow instruction: try to execute: Environment: Kubernetes version (use ):Cloud provider or hardware configuration:OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools:Others:
/sig network
I have exactly the same problem with the 1.12.0-beta.1. Does kube-proxy really need access to /proc/sys/* in this case?
Same problem with Ubuntu
Does that mean kube-proxy can only be run outside of container?
/sig cluster-lifecycle
/milestone v1.12
Looks like docker inspect shows masked and read-only paths (looking at ) even when the pod is
It being close to release, since this is not urgent, please save this for 1.13! /milestone clear /milestone v1.13
/milestone v1.13
/priority critical-urgent /milestone v1.12 Sorry the activity and urgency is reflected in the PR :)
welp! sorry about that!
I'm still seeing this on RC1, did this land before the release was cut? /cc
update from :
I just verified on release-1.12 branch and it's good.
Change:
"net.ipv4.ip_unprivileged_port_start", "net.ipv4.ip_local_reserved_ports", "net.ipv4.tcp_keepalive_time", <ins> "net.ipv4.tcp_fin_timeout", "net.ipv4.tcp_keepalive_intvl", "net.ipv4.tcp_keepalive_probes", </ins> }, }, }

Discussion:
Add the following to be safe sysctls: net.ipv4.tcpfintimeout net.ipv4.tcpkeepaliveintvl net.ipv4.tcpkeepaliveprobes These are related settings to net.ipv4.tcpkeepalivetime that was enabled in These are related ipv4 TCP settings for tuning network connections between a client and a pod.
/sig network
May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node. /sig nodes 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
/sig node
I adjusted it with the plugin.
Would this change apply at the node level or the pod level? I assumed it would be at the pod level, and should not affect any other pods--however Kubernetes does not natively have any limits on network connections that I am aware of--but only the pod with the changed net settings would be affected.
To verify that a sysctl has an effect on other pods, we need to verify that it's a namespace sysctl.
Here's a simple test Use net.ipv4.tcpfintimeout sysctl to create a container check if it set on the host =It is the default value on host run another container attach to the network namespace of the one where the sysctl is set =results in sysctl being set Verify in another container under a different network namespace that it is not set =It is the default value According to the test results, net.ipv4.tcpfintimeout is a namespaced sysctl
I likewise verified and , which are also namespaced sysctl, and I believe we can add them to the safe sysctl /assign
Probably need to wait for to finish before start working on it
/triage accepted
Change:
} // podFitsOnNode checks whether a node given by NodeInfo satisfies the given predicate functions. <ins> // For given pod, podFitsOnNode will check if any equivalent pod exists and try to reuse its cached // predicate results as possible. </ins> // This function is called from two different places: Schedule and Preempt. // When it is called from Schedule, we want to test whether the pod is schedulable // on the node with all the existing pods on the node plus higher and equal priority

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Today, . This seems unnecessary and should be done once for all the nodes. Is this a BUG REPORT or FEATURE REQUEST?: /kind enhancement /sig scheduling cc:
/assign Thanks, will send fix per slack discussion.
/cc
Change:
"cors.go", "doc.go", "goaway.go", <ins> "hsts.go", </ins> "longrunning.go", "maxinflight.go", "priority-and-fairness.go",

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add the "Strict-Transport-Security" header to the API server responses. Why is this needed: Nessus scanner treats this as a Medium Risk in kubernetes 1.18.10.
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 api-machinery
/remove-sig api-machinery /sig auth
Change:
import ( "bytes" "encoding/json" <ins> "fmt" </ins> "io/ioutil" "reflect" "time"

Discussion:
We have , but there isn't a label in the k/k repo. There is only . Do we need to add a label or rename to ?
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 .
/sig ui :smiley:
/sig contributor-experience
/cc
I just it. Fixed?
Yeah. BTW, the page has a bad md format. It also should be fixed.
Feel free to send a PR to fix :)
As Piotr is the owner, I thought let him fix:) If it's Okay, I will do. Thanks Christoph!
anyone can contribute to the kubernetes/community repo too :) the PR would be reviewed like any other (usually the sig-lead for that sig would review)
Okay:)
Yep just fix things when you can. That's just faster :)
FWIW this lead me to open

I can see that this message is flooding my minion logs so I was curious what should this config file looks like. I was trying to find some example, but with no luck. Also is this config file created during the runtime? What actually creates it? Shouldn't we just give up when the config file does not exists? Also there are better ways (maybe) to do polling if the file exists or not. I meaning you can use inotify () instead of an infinite loop + sleep. I'm happy to make a patch if you think it is a good idea. PS: I know that you put the timeout 5 seconds before retries.
Thanks for the report. I think this is just a bug-- we should check whether it exists and not pollute the log. I'm pretty sure we don't currently even use that file. Also we should NOT be reading the proxy's config from a file in /tmp where anybody can write it. Bad default location.
Proxy config sounds like an /etc thing, same for kubelet's container manifests from disk
Are we interested in polling for the configuration files changes? Or do we want to read the settings just once, as an ordinary unix binary?
Yes, polling is a requirement. This is a live config file like the kubelet's machine files.
Change:
Long:    editLong, Example: fmt.Sprintf(editExample), Run: func(cmd *cobra.Command, args []string) { <del> args = append([]string{"configmap"}, args...) </del> err := RunEdit(f, out, errOut, cmd, args, options) cmdutil.CheckErr(err) }, ValidArgs:  validArgs, ArgAliases: argAliases, } <del> addEditFlags(cmd, options) cmd.AddCommand(NewCmdEditConfigMap(f, out, errOut)) return cmd } func addEditFlags(cmd *cobra.Command, options *resource.FilenameOptions) { </del> usage := "to use to edit the resource" cmdutil.AddFilenameOptionFlags(cmd, options, usage) cmdutil.AddValidateFlags(cmd)

Discussion:
kubectl edit is not working on HEAD. It's working on 1.5.
Change:
Corefile: | .:53 { errors <del> log stdout </del> <ins> log </ins> health <del> kubernetes {{ pillar['dns_domain'] }} {{ pillar['service_cluster_ip_range'] }} </del> <ins> kubernetes {{ pillar['dns_domain'] }} {{ pillar['service_cluster_ip_range'] }} { pods insecure } </ins> prometheus proxy . /etc/resolv.conf cache 30

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG What happened: When CoreDNS is deployed by default using feature-gates of kubeadm, it does not log anything when processing a DNS query. That is due to change of log option of CoreDNS in latest version. that version was bumped up in kubeadm, but the manifest was not adapted to the new log option. initial change of 'log stdout' in CoreDNS : version of CoreDNS 1.0.0 bumped into Kubeadm : NOTE: I guess we should also changed manifests for kube-up : see The change in manifest expected is to remove the option "stdout" in the line "log ...". As it is now interpreted as a scope of domain to log. Invalid manifest: Environment: Kubernetes version (use ): 1.9 and MAIN Cloud provider or hardware configuration: any Install tools: kubeadm, kube-up the configmap for coredns kubectl get configmaps -n kube-system coredns -o yaml kubectl replace -f - the coredns deployment kubectl scale deployment --replicas=0 -n kube-system coredns kubectl scale deployment --replicas=1 -n kube-system coredns
/cc /sig network
NOTE: only log is impacted. CoreDNS working as expected.
/cc
I have a question : the initial manifest is done for the image 0.9.10 of CoreDNS. Bumping the version of CoreDNS was done by changing the version in file (see ) which means that the image's version is STILL 0.9.10 in the manifests ... and the corefile config is correct against the version of the manifest. QUESTION: when modifying the , is there a way to upgrade the manifest by program ? I guess at the time the new version number is applied on the manifest ...
thanks for reporting this! I send PR to update the Corefile. I don't think of a way so far. I guess we can't unless there is a way to get the Corefile from some place of upstream (CoreDNS).
Change:
} // Initialize passes a Kubernetes clientBuilder interface to the cloud provider <del> func (c *Cloud) Initialize(clientBuilder controller.ControllerClientBuilder) {} </del> <ins> func (c *Cloud) Initialize(clientBuilder controller.ControllerClientBuilder) { c.clientBuilder = clientBuilder c.kubeClient = clientBuilder.ClientOrDie("cloud-provider") c.eventBroadcaster = record.NewBroadcaster() c.eventBroadcaster.StartLogging(glog.Infof) c.eventBroadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: v1core.New(c.kubeClient.CoreV1().RESTClient()).Events("")}) c.eventRecorder = c.eventBroadcaster.NewRecorder(scheme.Scheme, v1.EventSource{Component: "aws-cloudprovider"}) } </ins> // Clusters returns the list of clusters. func (c *Cloud) Clusters() (cloudprovider.Clusters, bool) {

Discussion:
On AWS when we call "attach" of a volume then we periodically we check (via API call) if volume has indeed been attached. We run the check in a loop with timeout of 21 minutes. AWS documents that - if a volume is stuck in "attaching" state for too long, the node where volume is being attached is in "dirty" state and must be rebooted to fix the problem. Until node is rebooted, more pods with volumes to same node is only going be stuck in same state (i.e "attaching"). We propose that - if attach operation times out waiting for volume in "attaching" state, we should simply taint the node so as it can not affect other pods and a admin can manually fix the node. /sig aws /sig storage cc
Change:
effect: "NoSchedule" containers: - name: kube-proxy <del> image: {{pillar['kube_docker_registry']}}/kube-proxy:{{pillar['kube-proxy_docker_tag']}} </del> <ins> image: {{pillar['kube_docker_registry']}}/kube-proxy-amd64:{{pillar['kube-proxy_docker_tag']}} </ins> resources: requests: cpu: {{ cpurequest }}

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-alpha-features Which test(s) are failing: BeforeSuite Since when has it been failing: Failing since 7/18 The failure seems to have been introduced in is the only PR within that window that modifies any cluster configuration. This PR is related to Testgrid link: Reason for failure: kube-proxy is stuck in a pending state /milestone v1.16 /priority critical-urgent /kind failing-test /sig testing /sig cluster-lifecycle /cc
almost definitely related to the image change E0725 05:54:40. 1368 ] container start failed: ErrImagePull: rpc error: code = Unknown desc = Error response from daemon: manifest for not found
/assign
hmm, we should watch to ensure that actually fixed it /reopen
Reopened this issue. <detailsIn response to : hmm, we should watch to ensure that actually fixed it /reopen 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
Cluster came up in the most recent run, however it looks like tests may fail (it's not done yet). That should be a new issue though. /close
Closing this issue. <detailsIn response to : Cluster came up in the most recent run, however it looks like tests may fail (it's not done yet). That should be a new issue though. 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