jiebi/CodeConvo huggingface dataset:
Change:
. [1] We've recently switched to Go 1.19, and because of this, the E2E image has started failing to build recently [2] with the error: Using ` directly doesn't work either: [1] [2] The image should be buildable. /sig testing /priority important-soon N/A N/A N/A <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
please see the PR and lgtm if it works right for you!

Discussion:
docker run --rm -i -v "${TARGET}:${TARGET}:Z" registry.k8s.io/build-image/kube-cross:${KUBE_CROSS_VERSION}  /bin/bash -c " mkdir -p /go/src /go/bin &&  <del> GO111MODULE=on go get -d k8s.io/sample-apiserver@v0.17.0 &&  GO111MODULE=on CGO_ENABLED=0 GOARM=${GOARM} GOOS=${OS} GOARCH=${ARCH} go get k8s.io/sample-apiserver@v0.17.0 &&  </del> <ins> git clone https://github.com/kubernetes/sample-apiserver /go/src/k8s.io/sample-apiserver &&  cd /go/src/k8s.io/sample-apiserver &&  git checkout tags/v0.17.0 &&  go mod tidy &&  GO111MODULE=on CGO_ENABLED=0 GOARM=${GOARM} GOOS=${OS} GOARCH=${ARCH} go install . &&  </ins> find /go/bin -name sample-apiserver* -exec cp {} ${TARGET}/sample-apiserver ;" # for arm, go install uses /go/bin/linux_arm, so just find the file and copy it to the # root so we can copy it out from this throw away container image from a standard location.
Change:
release-master-blocking: gce-device-plugin-gpu-masterci-kubernetes-e2e-gce-device-plugin-gpu.Overall kubetest.Up 3rd November 2022 Up | 28m51s -- | -- { error during ./hack/e2e-internal/e2e- exit status 1} No response /sig cloud-provider cc
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
from:
we'll need to bump the node image i think:
Latest run is passing now!

Discussion:
if [[ "${KUBERNETES_PROVIDER}" == "gke" ]]; then detect-node-instance-groups <del> NODE_INSTANCE_GROUP=$(kube::util::join , NODE_INSTANCE_GROUPS) </del> <ins> NODE_INSTANCE_GROUP=$(kube::util::join , "${NODE_INSTANCE_GROUPS[@]}") </ins> fi ginkgo_args=()
Change:
One of the use-cases for APIServer tracing would be to try and debug SLO-violating requests served by the API Server. Right now, it adds just some basic attributes: For API Server , SLO-related metrics have the following labels: "verb", "dryrun", "group", "version", "resource", "subresource", "scope", "component", "code" We should add those labels to at least one of the spans created by API Server requests. It isn't a graduation requirement for , but would make the feature more helpful.
/sig instrumentation
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
We might be able to do something using RequestInfo, similar to how the dropped request metric is recorded:

Discussion:
return "unknown" } <ins> // lazyScope implements String() string and it will // lazily get Scope from request info type lazyScope struct { req *http.Request } func (lazy *lazyScope) String() string { if lazy.req != nil { ctx := lazy.req.Context() requestInfo, ok := apirequest.RequestInfoFrom(ctx) if ok { return metrics.CleanScope(requestInfo) } } return "unknown" } </ins>

resourceWithReq := &lazyResource{req: req.WithContext(ctx)} assert.Equal(t, "resource", fmt.Sprintf("%v", resourceWithReq)) } <ins> func TestLazyScope(t *testing.T) { assert.Equal(t, "unknown", fmt.Sprintf("%v", &lazyScope{})) scopeWithEmptyReq := &lazyScope{&http.Request{}} assert.Equal(t, "unknown", fmt.Sprintf("%v", scopeWithEmptyReq)) req := &http.Request{} ctx := request.WithRequestInfo(context.TODO(), &request.RequestInfo{Namespace: "ns"}) scopeWithReq := &lazyScope{req: req.WithContext(ctx)} assert.Equal(t, "namespace", fmt.Sprintf("%v", scopeWithReq)) } </ins>

attribute.Stringer("client", &lazyClientIP{req: req}), attribute.String("protocol", req.Proto), attribute.Stringer("resource", &lazyResource{req: req}), <ins> attribute.Stringer("scope", &lazyScope{req: req}), </ins> attribute.String("url", req.URL.Path), attribute.Stringer("user-agent", &lazyTruncatedUserAgent{req: req}), attribute.Stringer("verb", &lazyVerb{req: req}),
Change:
pull-kubernetes-integration: ci-kubernetes-integration-master: [Aa]pply&width=5 runkubectlserversideapplytests Unclear, shows up in flakes in triage history as far back as it goes No response_ Representative failure: /sig api-machinery /cc
If I'm not wrong, SSA conflict error is a real test case and expected(). That test looks failing in I could not find any recent change about that but if there is a latency for discovery endpoint being populated, this test should be flaky for a long time.
Another thing is if we get this not found error from discovery, we are not cleaning it properly and that causes run_crd test fails with already exist.
That's a good point, it's hard to clean-up properly though on failures :-/. And yes, I don't think ssa is the problem here, the problem is in getting the api-resources.
Submitted PR to attempt to fix it, it doesn't solve the clean-up issue, but at least it should hide it well :-)
/triage accepted

Discussion:
local tries=5 for i in $(seq 1 $tries); do local output <del> output=$(kubectl "${kube_flags[@]:?}" api-resources --api-group mygroup.example.com -oname) </del> <ins> output=$(kubectl "${kube_flags[@]:?}" api-resources --api-group mygroup.example.com -oname || true) </ins> if kube::test::if_has_string "$output" resources.mygroup.example.com; then break fi
Change:
pull-kubernetes-integration TestLegacyServiceAccountTokenTracking (in top 10 list of flakes - ) 10/25 No response It looks like the number of warnings received is not consistent: No response /sig auth /assign /milestone v1.26 /priority important-soon we should resolve this flake before test freeze
/triage accepted

Discussion:
myConfig.BearerToken = string(test.secretTokenData) roClient := clientset.NewForConfigOrDie(&myConfig) dateBefore := time.Now().UTC().Format(dateFormat) <del> go func() { doServiceAccountAPIRequests(t, roClient, myns, true, true, false) }() doServiceAccountAPIRequests(t, roClient, myns, true, true, false) </del> <ins> var wg sync.WaitGroup concurrency := 5 for i := 0; i < concurrency; i++ { wg.Add(1) go func() { doServiceAccountAPIRequests(t, roClient, myns, true, true, false) wg.Done() }() } wg.Wait() </ins> dateAfter := time.Now().UTC().Format(dateFormat) liveSecret, err := c.CoreV1().Secrets(myns).Get(context.TODO(), test.secretName, metav1.GetOptions{}) if err != nil { t.Fatalf("Could not get secret: %v", err) } <del> if test.expectWarning && len(wh.warnings) != 8 { t.Fatalf("Expect 8 warnings, got %d", len(wh.warnings)) </del> <ins> // doServiceAccountAPIRequests has 4 API requests if test.expectWarning && len(wh.warnings) != 4*concurrency { t.Fatalf("Expect %d warnings, got %d", 4*concurrency, len(wh.warnings)) </ins> } if !test.expectWarning && len(wh.warnings) != 0 { t.Fatalf("Don't expect warnings, got %d", len(wh.warnings))
Change:
Since the last days there is an unusual rate of flakiness on kind jobs, but couldn't find a pattern ! While looking at one test failure and checking at the controller manager logs, there is a panic on the controller manager that makes the controller manager to restart and impacts on all the test that are running at that time. ` Lessons learned, we should not increase timeouts forever or these problems will go unnoticed, still, they are really hard to find and is not the first time that this happens, maybe Kubernetes is too good reconciling XD It will be great to have a tool that detect panics on the components /sig scheduling
/release blocker /priority important-soon /kind bug /cc
looks like the exit code matching doesn't handle a mix of terminated and unterminated containers, needs something like this:
big +1, a restart or panic detector on control plane components would be excellent
cc
this sounds like a nice project ^^^ but is better to check first with and , I see there are some scripts that parse and dump the logs here maybe we can add some thing to report them somehow?
/assign
oops, it's holiday in Poland /unassign /assign
/remove-sig scheduling
I can add the fix proposed by but the underlying problem is . I'll prepare a PR for each and see if we are ok merging both or just the hotfix.
commented on we'll merge the panic fix right away in either case
Fix and unit test is up

Discussion:
return nil, true, nil } <ins> // matchOnExitCodes returns a terminated container status that matches the error code requirement, if any exists. // If the returned status is non-nil, it has a non-nil Terminated field. </ins> func matchOnExitCodes(podStatus *v1.PodStatus, requirement *batch.PodFailurePolicyOnExitCodesRequirement) *v1.ContainerStatus { if containerStatus := getMatchingContainerFromList(podStatus.ContainerStatuses, requirement); containerStatus != nil { return containerStatus

return nil } <ins> // getMatchingContainerFromList returns the first terminated container status in the list that matches the error code requirement, or nil if none match. // If the returned status is non-nil, it has a non-nil Terminated field </ins> func getMatchingContainerFromList(containerStatuses []v1.ContainerStatus, requirement *batch.PodFailurePolicyOnExitCodesRequirement) *v1.ContainerStatus { for _, containerStatus := range containerStatuses { <ins> if containerStatus.State.Terminated == nil { // This container is still be terminating. There is no exit code to match. // TODO(#113855): Remove this check when it's guaranteed that the // container is terminated. continue } </ins> if requirement.ContainerName == nil || *requirement.ContainerName == containerStatus.Name { if containerStatus.State.Terminated.ExitCode != 0 { if isOnExitCodesOperatorMatching(containerStatus.State.Terminated.ExitCode, requirement) {

Phase: v1.PodFailed, ContainerStatuses: []v1.ContainerStatus{ { <del> Name: "main-container", </del> <ins> Name: "foo", }, { Name: "bar", </ins> State: v1.ContainerState{ Terminated: &v1.ContainerStateTerminated{ ExitCode: 2,
Change:
All kubemark tests started failing around 11-04. https://k8s- https://k8s- The testing framework is not able to schedule pods. hollow kubelets has errors like: Finally (when the test already failed) it changes to Suspected commit range: ci-kubernetes-kubemark-500-gce.Overall 11-04 https://k8s- No response No response /sig scalability
/triage accepted
/assign
None of the commits in the range looks indeed suspicious (mostly some endpointslice and metrics changes).
I forgot that the commit in the testgrid doesn't match the tested version. The real suspected range is Probably is a suspect.
It helped !

Discussion:
containertest "k8s.io/kubernetes/pkg/kubelet/container/testing" probetest "k8s.io/kubernetes/pkg/kubelet/prober/testing" kubetypes "k8s.io/kubernetes/pkg/kubelet/types" <ins> kubeletutil "k8s.io/kubernetes/pkg/kubelet/util" </ins> "k8s.io/kubernetes/pkg/util/oom" "k8s.io/kubernetes/pkg/volume" "k8s.io/kubernetes/pkg/volume/cephfs"

runtimeService internalapi.RuntimeService, containerManager cm.ContainerManager) *HollowKubelet { d := &kubelet.Dependencies{ <del> KubeClient:           client, HeartbeatClient:      heartbeatClient, ProbeManager:         probetest.FakeManager{}, RemoteRuntimeService: runtimeService, RemoteImageService:   imageService, CAdvisorInterface:    cadvisorInterface, Cloud:                nil, OSInterface:          &containertest.FakeOS{}, ContainerManager:     containerManager, VolumePlugins:        volumePlugins(), TLSOptions:           nil, OOMAdjuster:          oom.NewFakeOOMAdjuster(), Mounter:              &mount.FakeMounter{}, Subpather:            &subpath.FakeSubpath{}, HostUtil:             hostutil.NewFakeHostUtil(nil), </del> <ins> KubeClient:               client, HeartbeatClient:          heartbeatClient, ProbeManager:             probetest.FakeManager{}, RemoteRuntimeService:     runtimeService, RemoteImageService:       imageService, CAdvisorInterface:        cadvisorInterface, Cloud:                    nil, OSInterface:              &containertest.FakeOS{}, ContainerManager:         containerManager, VolumePlugins:            volumePlugins(), TLSOptions:               nil, OOMAdjuster:              oom.NewFakeOOMAdjuster(), Mounter:                  &mount.FakeMounter{}, Subpather:                &subpath.FakeSubpath{}, HostUtil:                 hostutil.NewFakeHostUtil(nil), PodStartupLatencyTracker: kubeletutil.NewPodStartupLatencyTracker(), </ins> } return &HollowKubelet{
Change:
When OwnerReferencesPermissionEnforcement admission plugin is enabled, StatefulSetAutoDeletePVC feature cannot delete PVCs when scaling down a StatefulSet. StatefulSetAutoDeletePVC deletes PVCs when scaling down a StatefulSet Kubernetes with OwnerReferencesPermissionEnforcement admission & StatefulSetAutoDeletePVC feature gate enabled For example, using local-up- a StatefulSet with some replicas and: down the statefulset. PVCs are still present && complains: No response <detailsToday's master, v1.27.0-alpha.0.46+-dirty </details<details</details<detailsFedora </details<details</details<details</details<details</details
cc /sig storage /sig apps
/assign /triage accepted /priority important-soon

Discussion:
} if utilfeature.DefaultFeatureGate.Enabled(features.StatefulSetAutoDeletePVC) { <del> role.Rules = append(role.Rules, rbacv1helpers.NewRule("update").Groups(legacyGroup).Resources("persistentvolumeclaims").RuleOrDie()) </del> <ins> role.Rules = append(role.Rules, rbacv1helpers.NewRule("update", "delete").Groups(legacyGroup).Resources("persistentvolumeclaims").RuleOrDie()) </ins> } return role
Change:
seems we have a problem in branch 1.23, this test has been flaking for some time Originally posted by in
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 release /sig scheduling /kind flake
/assign
I see the log line for the desired outcome, but after the test has already timed out: And we do see a lot of throttling by APF. I'll just reduce the number of pods the test creates, only in 1.23, as other release seem fine.
just to keep ourselves honest: /remove-sig scheduling :smile:
still seeing this flake in release-1.23 (e.g. 3 runs in a row in , where CI is still running on go1.17)
this single test is failing 100% of runs in the 1.23 PR I'm currently working on
the cherry picks are still open
test has been green since the backports merged

Discussion:
jobObj, err := createJobWithDefaults(ctx, clientSet, ns.Name, &batchv1.Job{ Spec: batchv1.JobSpec{ CompletionMode: &mode, <del> Completions:    pointer.Int32(500), Parallelism:    pointer.Int32(500), </del> <ins> Completions:    pointer.Int32(100), Parallelism:    pointer.Int32(100), </ins> BackoffLimit:   pointer.Int32(0), }, })
Change:
Both and are missing help texts.
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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

Discussion:
Namespace:      namespace, Subsystem:      subsystem, Name:           "compilation_duration_seconds", <ins> Help:           "CEL compilation time in seconds.", </ins> StabilityLevel: metrics.ALPHA, }), evaluationTime: metrics.NewHistogram(&metrics.HistogramOpts{ Namespace:      namespace, Subsystem:      subsystem, Name:           "evaluation_duration_seconds", <ins> Help:           "CEL evaluation time in seconds.", </ins> StabilityLevel: metrics.ALPHA, }), }
Change:
All the LoadBalancers tests It seems that for a long time IPVS and iptable implementations differ, it may be possible the test do some wrong assumptions? At this point is up to the IPVS maintainers if they want to run those tests or not, is ok if they don't have time to investigate to disable the tests, but we should not have flaky test running or we'll have a lot of noise /sig network /area ipvs /help
/sig network /area ipvs /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 : /sig network /area ipvs /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

Discussion:
var k8sBinDir = flag.String("k8s-bin-dir", "", "Directory containing k8s kubelet and kube-apiserver binaries.") <ins> var buildTargets = []string{ "cmd/kubelet", "cmd/kube-apiserver", "test/e2e_node/e2e_node.test", "vendor/github.com/onsi/ginkgo/ginkgo", } </ins> func buildGo() { glog.Infof("Building k8s binaries...") k8sRoot, err := getK8sRootDir() if err != nil { glog.Fatalf("Failed to locate kubernetes root directory %v.", err) } <del> cmd := exec.Command(filepath.Join(k8sRoot, "hack/build-go.sh")) </del> <ins> cmd := exec.Command(filepath.Join(k8sRoot, "hack/build-go.sh"), buildTargets...) </ins> cmd.Stdout = os.Stdout cmd.Stderr = os.Stderr err = cmd.Run()

return "", err } if _, err := os.Stat(filepath.Join(*k8sBinDir, bin)); err != nil { <del> return "", fmt.Errorf("Could not find kube-apiserver under directory %s.", absPath) </del> <ins> return "", fmt.Errorf("Could not find %s under directory %s.", bin, absPath) </ins> } return filepath.Join(absPath, bin), nil }
Change:
Keep running but not crashing Have a long volume attach path This corresponds to these lines We are using k0s <details</detailsbare metal <details</details<details</details<details</details<details</details
I turned to use the JSON logger, it is gorgeous no wonder it failed
related
/sig node storage
/cc
VolumeToAttach contains Pod pointers, so yes, I think we should not log the entire struct, and only log important parts to it. /triage accepted /help-wanted
/priority important-longterm /assign

Discussion:
logger.V(5).Info("Starting attacherDetacher.AttachVolume", "volume", volumeToAttach) err := rc.attacherDetacher.AttachVolume(logger, volumeToAttach.VolumeToAttach, rc.actualStateOfWorld) if err == nil { <del> logger.Info("attacherDetacher.AttachVolume started", "volume", volumeToAttach) </del> <ins> logger.Info("attacherDetacher.AttachVolume started", "volumeName", volumeToAttach.VolumeName, "nodeName", volumeToAttach.NodeName, "scheduledPods", klog.KObjSlice(volumeToAttach.ScheduledPods)) </ins> } if err != nil && !exponentialbackoff.IsExponentialBackoff(err) { // Ignore exponentialbackoff.IsExponentialBackoff errors, they are expected. // Log all other errors. <del> logger.Error(err, "attacherDetacher.AttachVolume failed to start", "volume", volumeToAttach) </del> <ins> logger.Error(err, "attacherDetacher.AttachVolume failed to start", "volumeName", volumeToAttach.VolumeName, "nodeName", volumeToAttach.NodeName, "scheduledPods", klog.KObjSlice(volumeToAttach.ScheduledPods)) </ins> } } }
Change:
test-cmd: runwaittests Dec 20 2022, 14:53:53 UTC+0100 No response No response /sig cli
/triage accepted /assign

Discussion:
len_sec=$((end_sec-start_sec)) set -o errexit kube::test::if_has_string "${output_message}" 'timed out waiting for the condition ' <del> kube::test::if_has_string "${len_sec}" '1' </del> <ins> test $len_sec -ge 1 && test $len_sec -le 2 </ins> # Clean deployment kubectl delete deployment dtest set +o nounset set +o errexit <del> } </del>  No newline at end of file <ins> } </ins>
Change:
Create a service , and manually create an Endpoints with an external IP address. Access the service proxy, it fails with 503, "no endpoints available for service ...". I would expect proxy to work (parity with pod-endpoint based Services). Note: 198.18.0.254 is RFC 6890 (reserved for benchmarking). I was using it to test timeout scenarios. With this example, I expect to timeout. Instead, it fails immediately with 503. If I comment out the below validation and compile kube-apiserver, it works as I expect: <details</details<detailsGKE </detailsNo response No response No response No response
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
/cc /cc
is ok to be able to use IPs that don't belong to pod so the apiserver can be used as a proxy to external endpoints? There were several CVEs on that area, or may remember better than me
No. Limiting the apiserver proxy to IPs set by an actor with pod status permissions is intentional
Xref
/remove-kind bug /kind documentation this is working as intended, if it is unclear this is as intended, we should improve documentation to make that clear
Agree it is WAI - what's the right place to document this? k/website or is ther an API doc-comment for /proxy/ that feeds into openapi? I don't see any obvious place to document the limitations of that sub-resource
Looks like addressed this but was inadvertently lost near August 2022.
should we remove this too?
Yeah, do you want to do it or shall I? Antonio Ojea
Tim Hockin

Discussion:
set_num_migs if [[ ${KUBE_USE_EXISTING_MASTER:-} == "true" ]]; then <ins> detect-master </ins> parse-master-env create-nodes elif [[ ${KUBE_REPLICATE_EXISTING_MASTER:-} == "true" ]]; then