jiebi/CodeConvo huggingface dataset:
Change:
// acceptedNames are the names that are actually being used to serve discovery. // They may be different than the names in spec. <ins> // +optional </ins> AcceptedNames CustomResourceDefinitionNames `json:"acceptedNames" protobuf:"bytes,2,opt,name=acceptedNames"` // storedVersions lists all versions of CustomResources that were ever persisted. Tracking these

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, the field on must be explicitly set to their zero-values due to the fact that they are not tagged . Ref: Why is this needed: If using a system that automatically compares the provided configuration to the current, it will produce a diff on the updated status after creation. In addition, making sure to explicitly set to zero-values is not the best user experience. I am happy to provide the fix if this change is approved! /cc /sig api-machinery /area custom-resources
marking them as seems ok, so that client-side validation doesn't complain if they are absent when submitting manifests, but they shouldn't need to be set to omitempty (and at this point, we likely wouldn't change the serialization) Those fields are changed by controllers after creation, so expecting the live API object to exactly match the status is not going to go well anyway.
Good point! I’ll open a fix for this. Yep! The specific system in question ignores fields that are not set at creation time by default when doing comparison, so if status fields are not included then it will not report a diff.
/assign
I opened a fix for this but CC'ed both you and Let me know if any additional effort is required. Thanks!
Change:
if err := o.drainer.DeleteOrEvictPods(list.Pods()); err != nil { pendingList, newErrs := o.drainer.GetPodsForDeletion(nodeInfo.Name) <del> fmt.Fprintf(o.ErrOut, "There are pending pods in node %q when an error occurred: %vn", nodeInfo.Name, err) for _, pendingPod := range pendingList.Pods() { fmt.Fprintf(o.ErrOut, "%s/%sn", "pod", pendingPod.Name) </del> <ins> if pendingList != nil { pods := pendingList.Pods() if len(pods) != 0 { fmt.Fprintf(o.ErrOut, "There are pending pods in node %q when an error occurred: %vn", nodeInfo.Name, err) for _, pendingPod := range pods { fmt.Fprintf(o.ErrOut, "%s/%sn", "pod", pendingPod.Name) } } </ins> } if newErrs != nil { <del> fmt.Fprintf(o.ErrOut, "following errors also occurred:n%s", utilerrors.NewAggregate(newErrs)) </del> <ins> fmt.Fprintf(o.ErrOut, "Following errors occurred while getting the list of pods to delete:n%s", utilerrors.NewAggregate(newErrs)) </ins> } return err }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: kubectl drain crashed with panic when apiserver connection disappeared while there were pods that couldn't be evicted/deleted (sorry, the problem is a bit hard to reproduce and the log was lost) What you expected to happen: kubectl drain should exit with a proper error message How to reproduce it (as minimally and precisely as possible): Try kubectl drain multiple times, interrupting the connection during eviction/deletion Anything else we need to know?: The here can be in case if returns an error, and will panic upon accessing : This causes the c Environment: Kubernetes version (use ): The problem is present as of but is also present in earlier versions (I have a fix for this bug)
/priority important-longterm /sig cli
Change:
## `filepath-securejoin` ## <del> [![Build Status](https://travis-ci.org/cyphar/filepath-securejoin.svg?branch=master)](https://travis-ci.org/cyphar/filepath-securejoin) </del> <ins> [![Build Status](https://github.com/cyphar/filepath-securejoin/actions/workflows/ci.yml/badge.svg)](https://github.com/cyphar/filepath-securejoin/actions/workflows/ci.yml) </ins> An implementation of `SecureJoin`, a [candidate for inclusion in the Go standard library][go#20126]. The purpose of this function is to be a "secure"

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:
By("creating a file in subpath") cmd := "touch /volume_mount/mypath/foo/test.log" <del> _, err = framework.RunHostCmd(pod.Namespace, pod.Name, cmd) </del> <ins> _, _, err = f.ExecShellInPodWithFullOutput(pod.Name, cmd) </ins> if err != nil { framework.Failf("expected to be able to write to subpath") } By("test for file in mounted path") cmd = "test -f /subpath_mount/test.log" <del> _, err = framework.RunHostCmd(pod.Namespace, pod.Name, cmd) </del> <ins> _, _, err = f.ExecShellInPodWithFullOutput(pod.Name, cmd) </ins> if err != nil { framework.Failf("expected to be able to verify file") }

Discussion:
Which jobs are failing: Tests which exec into containers and alter lifecycles Which test(s) are failing: All new tests introduced for api change which exec into containers New alpha subpathExpr tests [Feature:VolumeSubpathEnvExpansion][NodeAlphaFeature:VolumeSubpathEnvExpansion] Since when has it been failing: 27/February/2019 Testgrid link: https://k8s- Reason for failure: is only set in e2e tests and the binary is not available in node e2e tests Need to restructure and call the API rather than through the framework convenience function Anything else we need to know:
/sig node /sig storage /assign /cc
Change:
// The second state change (optional) is due to the CPU burst parameter, which HPA again responds to. // TODO The use of 3 states is arbitrary, we could eventually make this test handle "n" states once this test stabilizes. func (scaleTest *HPAScaleTest) run(name, kind string, rc *common.ResourceConsumer, f *framework.Framework) { <ins> const timeToWait = 15 * time.Minute </ins> rc = common.NewDynamicResourceConsumer(name, kind, int(scaleTest.initPods), int(scaleTest.totalInitialCPUUsage), 0, 0, scaleTest.perPodCPURequest, 200, f) defer rc.CleanUp() hpa := common.CreateCPUHorizontalPodAutoscaler(rc, scaleTest.targetCPUUtilizationPercent, scaleTest.minPods, scaleTest.maxPods) defer common.DeleteHorizontalPodAutoscaler(rc, hpa.Name) <del> rc.WaitForReplicas(int(scaleTest.firstScale)) </del> <ins> rc.WaitForReplicas(int(scaleTest.firstScale), timeToWait) </ins> if scaleTest.firstScaleStasis > 0 { rc.EnsureDesiredReplicas(int(scaleTest.firstScale), scaleTest.firstScaleStasis) } if scaleTest.cpuBurst > 0 && scaleTest.secondScale > 0 { rc.ConsumeCPU(scaleTest.cpuBurst) <del> rc.WaitForReplicas(int(scaleTest.secondScale)) </del> <ins> rc.WaitForReplicas(int(scaleTest.secondScale), timeToWait) </ins> } }

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:
continue } <del> glog.Infof("[cpumanager] reconcileState: updating container (pod: %s, container: %s, container id: %s, cpuset: "%v")", pod.Name, container.Name, containerID, cset) </del> <ins> glog.V(4).Infof("[cpumanager] reconcileState: updating container (pod: %s, container: %s, container id: %s, cpuset: "%v")", pod.Name, container.Name, containerID, cset) </ins> err = m.updateContainerCPUSet(containerID, cset) if err != nil { glog.Errorf("[cpumanager] reconcileState: failed to update container (pod: %s, container: %s, container id: %s, cpuset: "%v", error: %v)", pod.Name, container.Name, containerID, cset, err)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: On 1.8+ kubelet with --cpu-manager-policy=static, there is a constant stream of logging every 10 seconds or so in the following formats: for every pod, and for every privileged pod where update would fail but looks expected. What you expected to happen: First set of logs should probably be suppressed or to the debug level. Second set of logs should probably be better at distinguish expected case vs. unexpected case before logging that as errors. How to reproduce it (as minimally and precisely as possible): Run kubelet with , and watch /var/log/messages or similar. Anything else we need to know?: Environment: Kubernetes version (use ): 1.8.1 Cloud provider or hardware configuration: baremetal/onprem OS (e.g. from /etc/os-release): CentOS 7.4.1708 Kernel (e.g. ): 4.13.8- Install tools: custom Others:
/sig node
/cc
Thanks for filing this bug. Do you plan to work on fixing it too, or should we find someone to pick it up?
I can take a look and see what I can or cannot do with this.
"updating container" log line should be easy to deal with, it is doing a logging without setting a level, and if there is a convention on what should be the level of this type of logging (and similar in this file), I can submit a PR to add .V(x). support for it. Any preference on how the logging level should be handled?
I can help review . For the second part, it might be related to we left for ourselves in the CPU manager code. We should fetch the current resource config and only update the field.
volunteered to look into the second half of this.
Great. Regarding the second half, the best I can find so far indicates that the error is the result of attempting to modifying when the cgroup already has children. I will dig more also just to confirm.
Here is what I found:
Any update on the second part? Is it also fixed? Thanks.
This hasn't been fixed AFAIK. This error is only related to kube-proxy containers.
has there this issue related with kube-proxy been a solution, or it been ignorable?
Change:
Name: "should-be-removable-validating-webhook.k8s.io", Rules: []v1beta1.RuleWithOperations{{ Operations: []v1beta1.OperationType{v1beta1.Create}, <ins> // This will not match any real resources so this webhook should never be called. </ins> Rule: v1beta1.Rule{ <del> APIGroups:   []string{"*"}, APIVersions: []string{"*"}, Resources:   []string{"*"}, </del> <ins> APIGroups:   []string{""}, APIVersions: []string{"v1"}, Resources:   []string{"invalid"}, </ins> }, }}, ClientConfig: v1beta1.WebhookClientConfig{

Discussion:
This flaked 3/4 times in the last week. /priority failing-test /priority important-soon /sig api-machinery /kind flake
/assign
Pinging here for latest status on this. This test is now one of our top flakes failing pull-kubernetes-e2e-gce job 40 times.
Here's the latest test run results for this test to get more logs. https://k8s-
The error message is really similar to the one in I'm looking into if the fix for that will also be sufficient to fix this.
We may want to reopen this until the fix is shown to actually work /reopen
Thanks for taking care of this. I will monitor this test and ping you back here to close when appropriate.
No failure 2 days since the fix. the fix seemed to have worked. So please go ahead and close the issue. Thanks much.
/close
Change:
PodTerminated PodStatus = "Terminated" // PodUnknown means that we failed to obtain info about the pod. PodUnknown PodStatus = "Unknown" <ins> // PodSucceeded means that the pod has stopped without error(s) PodSucceeded PodStatus = "Succeeded" </ins> ) type ContainerStateWaiting struct {

Discussion:
This happened to me several times while debugging an e2e test. My branch was based on commit and had changes only to
docker inspect says the container exited 0
kubelet HTTP says the pod exited 0:
kubectl says it failed:
Events does not show any success or failure even. Seems like it doesn't show that for any pods, succeeded or failed.
Apiserver sees the exit code 0:
The problem might be related to there being zero values for startedAt or finishedAt. The command may have exited so quickly that docker could not record these values, and we may be somehow treating unset values for these as failure.
adding sleep 5 to my command causes docker to set the startedAt and finishedAt to reasonable values, but the pod still shows up as failed. Note that I use a different pod name each time I try to avoid that sort of obvious mistake.
So, the apiserver v1beta1 message knows that it is terminated with exit code 0. But, both kubectl and my go code in my go e2e test thing this means failed. I'm starting to suspect the conversion code.
The problem is that a v1beta1 pod can never see that a pod is failed or succeded. So it defaults to PodFailed. Grrrrrrraaaaahhhhhh!
In line 184 of
This is going to be confusing for people unless we change this.
I believe the latest fix for PodStatus should resolve the issue here. I will double confirm it before closing it.

We should do this after 1.7. xref /sig testing cc
Is this the task that needs completed - Add support to Ubuntu e2e test-infra
That is different, this is about running GPU tests as part of PR pre-submit tests. Right now we skip them because they are "[Serial]".
I can work on this issue in conjunction with . Is this issue just a matter of adding GPU tests to a different suite or are there more subtasks?
Anymore progress on this?
Thanks for the reminder. I just submitted an internal request for quota to run these tests. Once that is approved, I will add a PR in test-infra to run GPU tests on all k/k PRs. It will be non-blocking initially and then become blocking later on.
Awesome, thanks!
Change:
"k8s.io/client-go/util/workqueue/default_rate_limiters_test.go", "k8s.io/client-go/util/workqueue/delaying_queue_test.go", "k8s.io/client-go/util/workqueue/rate_limitting_queue_test.go", <del> "k8s.io/client-go/util/workqueue/timed_queue_test.go", </del> ], library = ":k8s.io/client-go/util/workqueue", tags = ["automanaged"], deps = [ "//vendor:k8s.io/apimachinery/pkg/util/wait", <del> "//vendor:k8s.io/client-go/pkg/api/v1", </del> "//vendor:k8s.io/client-go/util/clock", ], )

Discussion:
The TimedWorkQueue object appears to lack a critical feature of the original WorkOueue, namely that similar items are aggregated together. By adding the time member to to the key type, it ensures that (time, item) pairs are unique-- you can add the same item multiple times as long as the time differs. This removes the guarantee that two goroutines wouldn't process the same item at the same time.
Iirc, the timed queue feeds a regular queue, so the guarantee still holds
Sorry, I was thinking of the delaying queue, which does key correctly
I'm going to remove timed workqueue. It's used to gather metrics for queues used in the garbage collector. This feature is supported by a regular workqueue now.
Change:
func CheckDaemonPodOnNodes(f *framework.Framework, ds *appsv1.DaemonSet, nodeNames []string) func(ctx context.Context) (bool, error) { return func(ctx context.Context) (bool, error) { return checkDaemonPodStateOnNodes(ctx, f.ClientSet, ds, f.Namespace.Name, nodeNames, func(pod *v1.Pod) bool { <del> return podutil.IsPodAvailable(pod, ds.Spec.MinReadySeconds, metav1.Now()) </del> <ins> return podutils.IsPodAvailable(pod, ds.Spec.MinReadySeconds, metav1.Now()) </ins> }) } }

Discussion:
Several test/e2e/framework/* packages have as their only dependency on k/k. The following functions are shared that way: IsPodAvailable returns true if a pod is available; false otherwise. IsPodReady returns true if a pod is ready; false otherwise. VisitContainers invokes the visitor function with a pointer to every container spec in the given pod spec with type set in mask. If visitor returns false, visiting is short-circuited. VisitContainers returns true if visiting completes, false if visiting was short-circuited. AllFeatureEnabledContainers returns a ContainerType mask which includes all container types except for the ones guarded by feature gate. The feature gate check in AllFeatureEnabledContainers is problematic. E2E tests don't know what the feature gates in the cluster are. The rest of the functions look like something that could be moved into == Having the functions in makes it clearer that the checks only depend on aspects of the public API. Reduces dependencies of e2e/framework on k/k, in case that we want to move it into staging. Prevents accidentally using checks that only work in-tree (like feature gates).
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
/assign
Change:
[]metav1.TableRow{{Cells: []interface{}{"test14", "2/2", "Running", "9 (5d ago)", "<unknown>"}}}, }, { <del> // Test PodScheduled condition with reason WaitingForGates </del> <ins> // Test PodScheduled condition with reason SchedulingGated </ins> api.Pod{ ObjectMeta: metav1.ObjectMeta{Name: "test15"}, Spec:       api.PodSpec{Containers: make([]api.Container, 2)},

Discussion:
<img width="844" alt="image" src="" <img width="942" alt="image" src="" Here are some incorrect comments and function name about SchedulingGated Comments and function names need to be changed to SchedulingGated nothing No response <details</details<details</details<details</details<details</details<details</details<details</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
/assign
/sig scheduling
/remove-kind bug /kind cleanup
Change:
visible at runtime in the container. release: v1.9 file: test/e2e/common/downward_api.go <ins> - testname: PodTemplate lifecycle codename: '[sig-node] PodTemplates should run the lifecycle of PodTemplates [Conformance]' description: Attempt to create a PodTemplate. Patch the created PodTemplate. Fetching the PodTemplate MUST reflect changes. By fetching all the PodTemplates via a Label selector it MUST find the PodTemplate by it's static label and updated value. The PodTemplate must be deleted. release: v1.19 file: test/e2e/common/podtemplates.go </ins> - testname: LimitRange, resources codename: '[sig-scheduling] LimitRange should create a LimitRange with defaults and ensure pod has those defaults applied. [Conformance]'

Discussion:
This issue proposes the writing of a new test for the API endponts , , , and with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to these results from APIsnoop, we are lacking in test coverage and conformant tests for PodTemplate. We chose these three following endpoints for this mock test: - - Outline: PodTemplates, Expect no PodTemplates a PodTemplate (1), Expect no error PodTemplate (1), Ensure the same as how it was created PodTemplate (1) with label a=1, Expect no error PodTemplate (1), Expect label in returned data to be present PodTemplates by label a=1, Expect one PodTemplate PodTemplate (1) Expect no error PodTemplates, Expect no PodTemplates Fetch dependencies: This mock test is using client-go's standard functions to talk to the PodTemplate part of the API. If a test with these calls gets merged in, conformance will go up by 3 endpoints. /sig architecture /area conformance
We decided not to deprecate. We can link to that, but otherwise this is OK to write / promote.
ref: for the decision not to deprecate
/reopen
Reopened this issue. <detailsIn response to : /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
Change:
"fmt" "io/ioutil" <ins> "k8s.io/apimachinery/pkg/runtime" </ins> "k8s.io/apimachinery/pkg/runtime/schema" <ins> "k8s.io/apimachinery/pkg/runtime/serializer" </ins> auditinternal "k8s.io/apiserver/pkg/apis/audit" auditv1 "k8s.io/apiserver/pkg/apis/audit/v1" "k8s.io/apiserver/pkg/apis/audit/validation" "k8s.io/apiserver/pkg/audit" "k8s.io/klog/v2" )

Discussion:
Currently the [audit policy decoder][1] silently drops unknown fields. For backwards compatibility, we probably cannot fail on unknown fields, but it would be good to at least log a warning when they're encountered. [1]: /sig api-machinery
/triage accepted
/help
This request has been marked as needing help from a contributor. 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 : /help 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
I'm not familiar with apiserver, but this seems like a simple one. /assign
How can we find unknown fields in the yaml file? Currently I'm think of converting both the yaml file and the decoded Policy struct to two map[string]interface{}, and compare both map to find out which keys are in the yaml file but not in the decoded struct, is there any better solution?
Courtesy on slack: