jiebi/CodeConvo huggingface dataset:
Change:
[X] test approval issue : [X] test pr : 26 May 2023 [x] two weeks soak end date : 9 June 2023 [x] test promotion pr : [x] remove endpoint from [x] End of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection. According to following APIsnoop query, there are still 3 CSIDriver endpoints that are not tested for Conformance. Using a number of existing e2e test practices a new has been created to address these 3 endpoints. The e2e logs for this test are listed below. This query shows the following csiDriver endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/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
/reopen For end of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection.
Reopened this issue. <detailsIn response to : /reopen For end of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection. 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

Discussion:
pod. release: v1.19 file: test/e2e/scheduling/preemption.go <ins> - testname: CSIDriver, lifecycle codename: '[sig-storage] CSIInlineVolumes should run through the lifecycle of a CSIDriver [Conformance]' description: Creating two CSIDrivers MUST succeed. Patching a CSIDriver MUST succeed with its new label found. Updating a CSIDriver MUST succeed with its new label found. Two CSIDrivers MUST be found when listed. Deleting the first CSIDriver MUST succeed. Deleting the second CSIDriver via deleteCollection MUST succeed. release: v1.28 file: test/e2e/storage/csi_inline.go </ins> - testname: CSIInlineVolumes should support Pods with inline volumes codename: '[sig-storage] CSIInlineVolumes should support CSIVolumeSource in Pod API [Conformance]'

} }) <del> ginkgo.It("should run through the lifecycle of a CSIDriver", func(ctx context.Context) { </del> <ins> /* Release: v1.28 Testname: CSIDriver, lifecycle Description: Creating two CSIDrivers MUST succeed. Patching a CSIDriver MUST succeed with its new label found. Updating a CSIDriver MUST succeed with its new label found. Two CSIDrivers MUST be found when listed. Deleting the first CSIDriver MUST succeed. Deleting the second CSIDriver via deleteCollection MUST succeed. */ framework.ConformanceIt("should run through the lifecycle of a CSIDriver", func(ctx context.Context) { </ins> // Create client client := f.ClientSet.StorageV1().CSIDrivers() defaultFSGroupPolicy := storagev1.ReadWriteOnceWithFSTypeFSGroupPolicy
Change:
broke rbac permissions for pod nanny and it's now not able to scale up with number of nodes. We see in kube-apiserver logs: I tried to fix naively the problem by but it's incomplete as we still see: which means that we are missing more permissions (e.g. get deployments). Sample test run where we see it: At this stage I gave up. /sig instrumentation /cc podnany has access to required data to scale up metrics-server Create empty cluster, watch kube-apiserver logs for podnanny user agent Also you can test e2e by calling '/test pull-kubernetes-e2e-gce-100-performance' and seeing if metrics-server ever resizes. No response <detailsmaster </details<detailsgce </details<details</details<details</details<details</details<details</details
We incorrectly removed RBAC required by metrics-server-nanny. Fixing this should require adding it back. List of permission that should work I would also recommend 2 followups for metrics server project: Make k/k metrics server configuration based on metrics-server project autoscaling configuration. This would require making the autoscaling part of release, releasing the config for v0.6.3, updating k/k repo with it and documenting it as instructions for updating metrics server config in k/k repo. Add tests no errors in nanny used in metrics server autoscaling configuration.
/assign
cc
ok, let me take a look
yeah, I think We dropped some resources which are needed. Let me try to add them back
/triage accepted /assign

Discussion:
- get - list - watch <ins> - apiGroups: ["apps"] resources: - deployments resourceNames: - metrics-server-v0.6.3 verbs: - get - patch - nonResourceURLs: - /metrics verbs: - get </ins> --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding
Change:
fails with the latest Go 1.21 dev branch, with: Test should pass but it fails. Build the latest Go tree from source (or wait for Go 1.21 rc1). Then run: FORCEHOSTGO=y make test WHAT=./cmd/kubeadm/app/cmd/phases/workflow This test is in . It is comparing function pointers by using reflect on the function value and then checking .Pointer. This typically does work for ordinary functions, but the test is comparing closures instead. If the closures were created by calling the same function twice, they may be different closures. This is why Go does not support function equality directly at all (which is why the test is resorting to reflect and non-guaranteed behavior). The closures appear to come from, among other places, cobra.ExactArgs: The Kubernetes test itself needs to be rewritten not to depend on function pointer equality. In fact, as the comment notes, in the earlier Go implementation, checking .Pointer made it appear that ExactArgs(1) == ExactArgs(3), because Pointer only looks at the code pointer, not the associated data pointer: The test is already running the function to test that it behaves correctly. The Pointer comparison should simply be deleted. Happens at HEAD and in v1.27.1. N/A Linux, irrelevant. N/A N/A N/A
thanks for logging the issue makes sense! /assign /area kubeadm /sig cluster-lifecycle
/triage accepted
fix is here:
Added fix PR reference to to ensure it gets backported so release branches can pick up go1.21

Discussion:
continue } <del> // Ensure it is the expected function if reflect.ValueOf(cCmd.Args).Pointer() != reflect.ValueOf(args.args).Pointer() { t.Error("The function pointers where not equal.") } </del> // Test passing argument set err := cCmd.Args(cCmd, args.pass) if err != nil { t.Errorf("command %s should validate the args: %vn %v", cCmd.Name(), args.pass, err) }
Change:
Apply this patch: Then run: make test WHAT=./pkg/volume/git_repo The test fails: Test should pass. See above. The full loop is: The first problem is that fakeOutputs is capturing , so all the funcs on that list use the from the final iteration, not the one from the iteration with the [1] == "clone". But then this problem appears to be covering up a different problem in the test scenarios themselves. I looked at it for a little bit but I haven't puzzled out what the test is trying to do exactly. Hopefully someone with more knowledge of the test can take a look. It seems like a buggy test, accidentally passing due to this other loopvar sharing bug. HEAD N/A N/A N/A N/A N/A
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 storage /priority important-soon /cc Thanks for the report and the detailed explanation
/assign
I wonder if it could be beneficial to invest some time and effort to identify a maximum of loops that contain the loopvar sharing bug maybe with comment and a todo ?

Discussion:
"fmt" "io/ioutil" "os" <ins> "path" </ins> "path/filepath" "reflect" "strings"

var fakeOutputs []fakeexec.FakeAction var fcmd fakeexec.FakeCmd for _, expected := range expecteds { <ins> expected := expected </ins> if expected.cmd[1] == "clone" { <ins> // Calculate the subdirectory clone would create (if any) // git clone -- https://github.com/kubernetes/kubernetes.git target_dir --> target_dir // git clone -- https://github.com/kubernetes/kubernetes.git            --> kubernetes // git clone -- https://github.com/kubernetes/kubernetes.git .          --> . // git clone -- https://github.com/kubernetes/kubernetes.git ./.        --> . cloneSubdir := path.Base(expected.cmd[len(expected.cmd)-1]) if cloneSubdir == "kubernetes.git" { cloneSubdir = "kubernetes" } </ins> fakeOutputs = append(fakeOutputs, func() ([]byte, []byte, error) { // git clone, it creates new dir/files <del> os.MkdirAll(filepath.Join(fcmd.Dirs[0], expected.dir), 0750) </del> <ins> os.MkdirAll(filepath.Join(fcmd.Dirs[0], expected.dir, cloneSubdir), 0750) </ins> return []byte{}, nil, nil }) } else {

g := mounter.(*gitRepoVolumeMounter) g.exec = fake <del> g.SetUp(volume.MounterArgs{}) </del> <ins> err := g.SetUp(volume.MounterArgs{}) if err != nil { allErrs = append(allErrs, err) } </ins> if fake.CommandCalls != len(expecteds) { allErrs = append(allErrs,
Change:
Apply this patch: Then run: This fails with: Test should pass. See above. If there are N objects in claims.Items, then this loop for _, claim := range claims.Items { objects = append(objects, &claim) } is appending the same pointer N times, pointing at the final item in the list. Adding fixes that mistake, but then it makes the test fail. Something else about the test is buggy, but the bug was being masked by this bug. In the repro case I to the loop a few lines down, just for good measure, but that one is not causing a problem. The line by itself causes the test failure. HEAD N/A N/A N/A N/A N/A
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 scheduling /priority important-soon /cc Thanks for finding this and the detailed report
/assign
Can you help to fix this?
If we don't here from soonish, then I'll fix it myself.
Sorry, I've been busy with an office accident this week, if you want fix it, please take it
/assign
/unassign

Discussion:
Obj() inUseClaim = st.FromResourceClaim(pendingImmediateClaim). Allocation(&resourcev1alpha2.AllocationResult{}). <del> ReservedFor(resourcev1alpha2.ResourceClaimConsumerReference{UID: types.UID(podUID)}). </del> <ins> ReservedFor(resourcev1alpha2.ResourceClaimConsumerReference{Resource: "pods", Name: podName, UID: types.UID(podUID)}). </ins> Obj() allocatedClaim = st.FromResourceClaim(pendingDelayedClaim). OwnerReference(podName, podUID, podKind).

"claim-reference": { pod:    podWithClaimName, claims: []*resourcev1alpha2.ResourceClaim{allocatedClaim, otherClaim}, <ins> want: want{ reserve: result{ changes: change{ claim: func(claim *resourcev1alpha2.ResourceClaim) *resourcev1alpha2.ResourceClaim { if claim.Name == claimName { claim = claim.DeepCopy() claim.Status.ReservedFor = inUseClaim.Status.ReservedFor } return claim }, }, }, }, </ins> }, "claim-template": { pod:    podWithClaimTemplate, claims: []*resourcev1alpha2.ResourceClaim{allocatedClaim, otherClaim}, <ins> want: want{ reserve: result{ changes: change{ claim: func(claim *resourcev1alpha2.ResourceClaim) *resourcev1alpha2.ResourceClaim { if claim.Name == claimName { claim = claim.DeepCopy() claim.Status.ReservedFor = inUseClaim.Status.ReservedFor } return claim }, }, }, }, </ins> }, "missing-claim": { pod: podWithClaimTemplate,

claims, err := tc.client.ResourceV1alpha2().ResourceClaims("").List(tc.ctx, metav1.ListOptions{}) require.NoError(t, err, "list claims") for _, claim := range claims.Items { <ins> claim := claim </ins> objects = append(objects, &claim) } schedulings, err := tc.client.ResourceV1alpha2().PodSchedulingContexts("").List(tc.ctx, metav1.ListOptions{}) require.NoError(t, err, "list pod scheduling") for _, scheduling := range schedulings.Items { <ins> scheduling := scheduling </ins> objects = append(objects, &scheduling) }
Change:
Using the Go 1.21 dev branch, FORCEHOSTGO=y make test fails because the TLS bad certificate error has gotten more specific in Go 1.21. Test should pass. Use the command above with the Go 1.21 dev branch as your in your PATH. Here is the fix: HEAD N/A N/A N/A N/A N/A
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
Thank you very much /priority important-soon /cc The fix is already reported on the description, so this is an easy PR for people willing to contribute /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 : Thank you very much /priority important-soon /cc 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 architecture
/assign

Discussion:
) const ( <del> errBadCertificate    = "Get .*: remote error: tls: bad certificate" </del> <ins> errBadCertificate    = "Get .*: remote error: tls: (bad certificate|unknown certificate authority)" </ins> errNoConfiguration   = "invalid configuration: no configuration has been provided" errMissingCertPath   = "invalid configuration: unable to read %s %s for %s due to open %s: .*" errSignedByUnknownCA = "Get .*: x509: .*(unknown authority|not standards compliant|not trusted)"
Change:
master-informing ci-crio-cgroupv1-node-e2e-conformanceci-crio-cgroupv1-node-e2e-conformance.Overall kubetest.Node Tests E2eNode Suite.[It] [sig-node] Container Runtime blackbox test on terminated container should report termination message from log output if TerminationMessagePolicy FallbackToLogsOnError is set [NodeConformance] [Conformance] E2eNode Suite.[It] [sig-node] Kubelet when scheduling a busybox command in a pod should print the output to logs [NodeConformance] [Conformance] E2eNode Suite.[It] [sig-node] Kubelet when scheduling a read only busybox container should not write to root filesystem [LinuxOnly] [NodeConformance] [Conformance] E2eNode Suite.[It] [sig-node] Pods should support retrieving logs from the container over websockets [NodeConformance] [Conformance] ! 2023-05-15 12:08 PDT E2eNode Suite: [It] [sig-node] Pods should support retrieving logs from the container over websockets [NodeConformance] [Conformance] E2eNode Suite: [It] [sig-node] Kubelet when scheduling a read only busybox container should not write to root filesystem [LinuxOnly] [NodeConformance] [Conformance] E2eNode Suite: [It] [sig-node] Container Runtime blackbox test on terminated container should report termination message from log output if TerminationMessagePolicy FallbackToLogsOnError is set [NodeConformance] [Conformance] E2eNode Suite: [It] [sig-node] Kubelet when scheduling a busybox command in a pod should print the output to logs [NodeConformance] [Conformance] Node Tests No response /sig node cc
~partially blocked on edit: I got the compatibility matrix confused, this is not blocked on that
/reopen Better to close once we see it green
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
/assign /triage accepted Head over to the Slack thread if you want to see more discussion:
Working on a fix in
Green tests:

Discussion:
// initializeRuntimeDependentModules will initialize internal modules that require the container runtime to be up. func (kl *Kubelet) initializeRuntimeDependentModules() { if err := kl.cadvisor.Start(); err != nil { <del> kl.runtimeState.setInternalError(fmt.Errorf("failed to start cAdvisor %v", err)) </del> <ins> // Fail kubelet and rely on the babysitter to retry starting kubelet. // TODO(random-liu): Add backoff logic in the babysitter glog.Fatalf("Failed to start cAdvisor %v", err) </ins> } // eviction manager must start after cadvisor because it needs to know if the container runtime has a dedicated imagefs if err := kl.evictionManager.Start(kl, kl.getActivePods, evictionMonitoringPeriod); err != nil {
Change:
/kind flake /sig storage It seems the timeout is too short or should not apply to the cleanup of the test, since the test is failing because the context is canceled during the timeout
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
See

Discussion:
} for _, t := range tests { test := t <del> ginkgo.It(t.name, ginkgo.SpecTimeout(f.Timeouts.PodStart), func(ctx context.Context) { </del> <ins> ginkgo.It(t.name, ginkgo.NodeTimeout(f.Timeouts.PodStart), func(ctx context.Context) { </ins> scName := "mock-csi-storage-capacity-" + f.UniqueName m.init(ctx, testParameters{ registerDriver:  true,
Change:
I noticed that kube-controller-manager terminated with a concurrent map access: No concurrent map access, and no fatal error. No reproducer. I noticed this in an internal CI run. This appears to be an obvious (in retrospect) logic error with a straightforward solution, so I assume that it isn't necessary to provide a reproducer. This is from an OpenShift cluster based on Kubernetes 1.27. AWS. Red Hat Enterprise Linux CoreOS 414.92.-0. No response No response No response
/sig network
/assign
/triage accepted

Discussion:
return slicesToCreate, slicesToUpdate, events } <del> hintsEnabled := t.hintsPopulatedByService.Has(si.ServiceKey) t.SetHints(si.ServiceKey, si.AddressType, allocatedHintsByZone) </del> <ins> t.lock.Lock() defer t.lock.Unlock() hintsEnabled := t.hasPopulatedHintsLocked(si.ServiceKey) t.setHintsLocked(si.ServiceKey, si.AddressType, allocatedHintsByZone) </ins> // if hints were not enabled before, we publish an event to indicate we enabled them. if !hintsEnabled {

t.lock.Lock() defer t.lock.Unlock() <ins> t.setHintsLocked(serviceKey, addrType, allocatedHintsByZone) } func (t *TopologyCache) setHintsLocked(serviceKey string, addrType discovery.AddressType, allocatedHintsByZone EndpointZoneInfo) { </ins> _, ok := t.endpointsByService[serviceKey] if !ok { t.endpointsByService[serviceKey] = map[discovery.AddressType]EndpointZoneInfo{}

// HasPopulatedHints checks whether there are populated hints for a given service in the cache. func (t *TopologyCache) HasPopulatedHints(serviceKey string) bool { <ins> t.lock.Lock() defer t.lock.Unlock() return t.hasPopulatedHintsLocked(serviceKey) } func (t *TopologyCache) hasPopulatedHintsLocked(serviceKey string) bool { </ins> return t.hintsPopulatedByService.Has(serviceKey) }

go func() { cache.AddHints(logger, sliceInfo) }() <ins> go func() { cache.HasPopulatedHints(sliceInfo.ServiceKey) }() </ins> } // Test Helpers
Change:
After running k8s conformance testing on kubernetes v1.27, we have leftover custom resources of the format that should not exist. For example) Basic test instructions: We use the latest official kubernetes kubekins image: We extract kubetest binary from kubekins latest-master docker image. We run serial conformance tests as follows. We also run parallel conformance tests as follows.
/sig api-machinery
The following script is used to cleanup the leftover CRDs:
/triage accepted /assign /cc
/area conformance
/sig architecture

Discussion:
kind: %s metadata: name: %s <del> finalizers: - test-finalizer </del> spec: foo: foo1 cronSpec: "* * * * */5"

kind: %s metadata: name: %s <del> finalizers: - test-finalizer </del> spec: unknown: uk1 cronSpec: "* * * * */5"

kind: %s metadata: name: %s <del> finalizers: - test-finalizer </del> unknownField: unknown spec: foo: foo1

metadata: name: %s unknownMeta: unknown <del> finalizers: - test-finalizer </del> spec: template: apiversion: foo/v1

framework.Failf("cannot create crd %s", err) } <ins> defer func() { err = fixtures.DeleteV1CustomResourceDefinition(noxuDefinition, apiExtensionClient) framework.ExpectNoError(err, "deleting CustomResourceDefinition") }() </ins> kind := noxuDefinition.Spec.Names.Kind apiVersion := noxuDefinition.Spec.Group + "/" + noxuDefinition.Spec.Versions[0].Name name := "mytest"

kind: %s metadata: name: %s <del> finalizers: - test-finalizer </del> spec: unknown: uk1 foo: foo1

Param("fieldValidation", "Strict"). Body(yamlBody). DoRaw(ctx) <del> if !(strings.Contains(string(result), `line 11: key "foo" already set in map`)) { </del> <ins> if !(strings.Contains(string(result), `line 9: key "foo" already set in map`)) { </ins> framework.Failf("error missing duplicate field: %v:n%v", err, string(result)) } })
Change:
In Kubernetes 1.26, Kubernetes Enhancement Proposal, KEP-3352[1]: Aggregated Discovery, enhanced the discovery mechanism and supported aggregated discovery optimizing response for discovery api. To support this KEP, Changes were made to both API server and client to support aggregated discovery mechanism. This feature was available alpha in Kubernetes 1.26 behind a feature flag, . In Kubernetes 1.27, aggregated discovery endpoint was promoted to beta and enabled by default[2]. Here is a class of problems that ended up getting triggered. GOOD NEWS!! is that it is already fixed by in 1.27 and a cherry pick in 1.26 For example, With Prometheus adapter, we saw issues across repositories: One signature of this is following in the traceback:
Searching for that method signature: Currently shows the following:
Leaving this open for some time, just to serve as a point of coordination if needed. The advice/guidance here is for folks to update to newer versions of 1.26/1.27 client-go.
/sig api-machinery
Components that do generate custom metrics (grepping through sources!): etc..
Thanks, Any custom server, sending nil GVK could trigger this bug. So far have seen it through custom metrics via promethus-adapter.
Thanks for tracking this /cc /triage accepted
For those searching in the future, the impacted versions are: 26.0 - 0.26.3 The fixed versions are: 26.4+ As well as updating , make sure that your other dependencies do not pull in any of the affected versions.
/close i think that's about it for now..
Closing this issue. <detailsIn response to : /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

Discussion:
"flag" "fmt" "log" <ins> "math/rand" </ins> "net" "os" "strconv"

func main() { flag.Parse() <ins> rand.Seed(time.Now().UTC().UnixNano()) </ins> // Set up logger for etcd client etcd.SetLogger(log.New(os.Stderr, "etcd ", log.LstdFlags))