jiebi/CodeConvo huggingface dataset:
Change:
Since last Friday scalability test become red/very flaky Affected jobs: Those failure are related to failed jobs. Sample test output: Working hypothesis is that code change from , but this requires confirmation.
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 scalability
This particular regression is purely Job-related (we only see problems with batchv1.Job objects). /sig apps /priority critical-urgent - FYI /milestone v1.22
/assign
After internal testing it seems that can be a fix. Added big scale presubmits to

Discussion:
return p.Status.Phase == v1.PodSucceeded })) failed += int32(countValidPodsWithFilter(job, pods, uncounted.Failed(), func(p *v1.Pod) bool { <del> // Counting deleted Pods as failures to account for orphan Pods that never // have a chance to reach the Failed phase. return p.Status.Phase == v1.PodFailed || (p.DeletionTimestamp != nil && p.Status.Phase != v1.PodSucceeded) </del> <ins> if p.Status.Phase == v1.PodFailed { return true } // When tracking with finalizers: counting deleted Pods as failures to // account for orphan Pods that never have a chance to reach the Failed // phase. return uncounted != nil && p.DeletionTimestamp != nil && p.Status.Phase != v1.PodSucceeded </ins> })) return succeeded, failed }

wantFailed:    4, }, "deleted pods": { <ins> pods: []*v1.Pod{ buildPod().uid("a").phase(v1.PodSucceeded).deletionTimestamp().Pod, buildPod().uid("b").phase(v1.PodFailed).deletionTimestamp().Pod, buildPod().uid("c").phase(v1.PodRunning).deletionTimestamp().Pod, buildPod().uid("d").phase(v1.PodPending).deletionTimestamp().Pod, }, wantSucceeded: 1, wantFailed:    1, }, "deleted pods, tracking with finalizers": { </ins> job: batch.Job{ Status: batch.JobStatus{ Succeeded:               1,
Change:
ci-kubernetes-e2e-gce-scale-correctness Kubernetes e2e suite: [sig-node] SSH should SSH to all nodes and run commands kubetest.Test Jul 10 14:01:51 UTC+0200 Kubernetes e2e suite: [sig-node] SSH should SSH to all nodes and run commands: more . Test /sig node
/cc
/triage accepted
Uhhh, this may help here
/milestone v1.22
/sig scalability FYI
I got annoyed that I couldn't click through to see the other logs, so now you can, ref: (spyglass doesn't render build- because it's 500MB, and the limit for rendering is 100MB)
/assign SIG Scalability chairs/TLs, please find someone to address or call this a non-release-blocking failure
Assigning to current scalability oncall (): /assign
This is sig-node issue - should be addres by SIG-node folks. /sig node
is being discussed as a fix for this and I'm not sure it's correct
is it sig scalability's intent that 5k node clusters should support SSH?
The SSH test in question passes in the "default" job: So the fact that this failure is unique to a scalability job means to me that scalability needs to own at least some part of this
I did a little bit of digging and ci-kubernetes-e2e-gce-scale-correctness uses option in kubetest, which according to seems to be setting KUBESSHBASTION env. So I believe this is main difference between our scalability job and "default".
Debugging the test in and providing a fix there. The crictl host PR () is doing something different.

Discussion:
// singleCallTimeout is how long to try single API calls (like 'get' or 'list'). Used to prevent // transient failures from failing tests. singleCallTimeout = 5 * time.Minute <ins> // sshBastionEnvKey is the environment variable key for running SSH commands via bastion. sshBastionEnvKey = "KUBE_SSH_BASTION" </ins> ) // GetSigner returns an ssh.Signer for the provider ("gce", etc.) that can be

// canConnect returns true if a network connection is possible to the SSHPort. func canConnect(host string) bool { <ins> if _, ok := os.LookupEnv(sshBastionEnvKey); ok { return true } </ins> hostPort := net.JoinHostPort(host, SSHPort) conn, err := net.DialTimeout("tcp", hostPort, 3*time.Second) if err != nil { <ins> e2elog.Logf("cannot dial %s: %v", hostPort, err) </ins> return false } conn.Close()

result.User = os.Getenv("USER") } <del> if bastion := os.Getenv("KUBE_SSH_BASTION"); len(bastion) > 0 { </del> <ins> if bastion := os.Getenv(sshBastionEnvKey); len(bastion) > 0 { </ins> stdout, stderr, code, err := runSSHCommandViaBastion(cmd, result.User, bastion, host, signer) result.Stdout = stdout result.Stderr = stderr

if err != nil { framework.Failf("Error getting node hostnames: %v", err) } <ins> ginkgo.By(fmt.Sprintf("Found %d SSH'able hosts", len(hosts))) </ins> testCases := []struct { cmd            string

ginkgo.By(fmt.Sprintf("SSH'ing to %d nodes and running %s", len(testhosts), testCase.cmd)) for _, host := range testhosts { <ins> ginkgo.By(fmt.Sprintf("SSH'ing host %s", host)) </ins> result, err := e2essh.SSH(testCase.cmd, host, framework.TestContext.Provider) stdout, stderr := strings.TrimSpace(result.Stdout), strings.TrimSpace(result.Stderr) if err != testCase.expectedError {
Change:
<!-- 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 --AppendReason panic when status is nil. Some plugins return nil to mean success. (Or, shouldn't be used on success status? I use field as a reason for why it is success.) not panic or describe this behaviour on the document
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 /assign I think there are some solutions we can take. just add this behaviour to AppendReason document. (most easy solution) Status when status is nil, like below. all plugins not to return nil when success (hard way..) I support the second idea.
I'd expect (and in fact it is) the caller to be responsible to ensure the status is not nil: The 2nd option may work, but semantically should be called by a non-success status.
Hi OK, I see :) I created the small PR to describe that reason field is for non-success status. Please take a look

Discussion:
} // Status indicates the result of running a plugin. It consists of a code, a <del> // message, (optionally) an error and an plugin name it fails by. When the status // code is not `Success`, the reasons should explain why. </del> <ins> // message, (optionally) an error and an plugin name it fails by. // When the status code is not Success, the reasons should explain why. // And, when code is Success, all the other fields should be empty. </ins> // NOTE: A nil Status is also considered as Success. type Status struct { code    Code
Change:
this job failed with It seems it is imssing some dependency The job history confirms it is totally broken 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 testing

Discussion:
) const ( <del> probeTimeOut = time.Minute </del> <ins> probeTimeOut = 20 * time.Second </ins> ) // TODO: this basic interface is duplicated in N places.  consolidate?

const ( DefaultEtcdPathPrefix = "/registry" <ins> globalTimeout         = time.Minute </ins> ) // StorageDestinations is a mapping from API group & resource to

if longRunningRequestCheck(req) { return nil, "" } <del> return time.After(time.Minute), "" </del> <ins> return time.After(globalTimeout), "" </ins> } if secureLocation != "" {
Change:
Unknown allowedTopology labels cause csi translation to fail: However, on GKE other labels are sometimes used in PV node affinity, such as or It's not common (100s of clusters as of July 2021), but seems enough that it should be dealt with. The suggestion is to just pass unknown topologies through. If they are used in the storageclass labels they will cause failures, but that is the current gce-pd behavior anyway. This reasoning probably holds for other clouds as well, although I haven't tested it myself. /assign /sig storage
/triage accepted

Discussion:
return nil } <del> // translateAllowedTopologies translates allowed topologies within storage class </del> <ins> // translateAllowedTopologies translates allowed topologies within storage class or PV </ins> // from legacy failure domain to given CSI topology key func translateAllowedTopologies(terms []v1.TopologySelectorTerm, key string) ([]v1.TopologySelectorTerm, error) { if terms == nil {

Key:    key, Values: exp.Values, } <del> } else if exp.Key == key { newExp = exp </del> } else { <del> return nil, fmt.Errorf("unknown topology key: %v", exp.Key) </del> <ins> // Other topologies are passed through unchanged. newExp = exp </ins> } newTerm.MatchLabelExpressions = append(newTerm.MatchLabelExpressions, newExp) }

name            string topology        []v1.TopologySelectorTerm expectedToplogy []v1.TopologySelectorTerm <del> expErr          bool </del> }{ { name:     "no translation",

}, }, }, <del> expErr: true, </del> <ins> expectedToplogy: []v1.TopologySelectorTerm{ { MatchLabelExpressions: []v1.TopologySelectorLabelRequirement{ { Key:    "test", Values: []string{"foo", "bar"}, }, }, }, }, </ins> }, } for _, tc := range testCases { t.Logf("Running test: %v", tc.name) gotTop, err := translateAllowedTopologies(tc.topology, GCEPDTopologyKey) <del> if err != nil && !tc.expErr { t.Errorf("Did not expect an error, got: %v", err) } if err == nil && tc.expErr { t.Errorf("Expected an error but did not get one") </del> <ins> if err != nil { t.Errorf("Unexpected error: %w", err) </ins> } if !reflect.DeepEqual(gotTop, tc.expectedToplogy) {
Change:
<!-- 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 --- ci-crio-cgroupv1-node-e2e-conformance many Many tests failing, they seem to be timing out. Example: Flakiness began late on 07/21 with this failure run: Note that cri-o jobs do not pin version of cri-o or Fedora CoreOS so it is possible the underlying components got bumped. /sig node
/cc
/milestone v1.22
I will take this /assign
/triage accepted
/remove-kind flake /kind failing-test as stats/summary test is now continuously failing
it is hard to tell because the tests were very flaky before, but I am suspicious of for causing the perma-failures. I have opened to test, where we can compare the difference in failures. It's possible this is just due to some crio configuration not being happy with the metrics server bump
/milestone v1.23
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /remove-kind failing-test /kind flake back to flaking:
it looks like the major page fault value is a bit off. I've opened to fix

Discussion:
}) } expectedPageFaultsUpperBound := 1000000 <del> expectedMajorPageFaultsUpperBound := 10 </del> <ins> expectedMajorPageFaultsUpperBound := 15 </ins> if IsCgroup2UnifiedMode() { // On cgroupv2 these stats are recursive, so make sure they are at least like the value set // above for the container.

"UsageBytes":      bounded(10*e2evolume.Kb, 80*e2evolume.Mb), "WorkingSetBytes": bounded(10*e2evolume.Kb, 80*e2evolume.Mb), "RSSBytes":        bounded(1*e2evolume.Kb, 80*e2evolume.Mb), <del> "PageFaults":      bounded(100, 1000000), "MajorPageFaults": bounded(0, 10), </del> <ins> "PageFaults":      bounded(100, expectedPageFaultsUpperBound), "MajorPageFaults": bounded(0, expectedMajorPageFaultsUpperBound), </ins> }), "Accelerators": gomega.BeEmpty(), "Rootfs": ptrMatchAllFields(gstruct.Fields{

"UsageBytes":      bounded(10*e2evolume.Kb, 80*e2evolume.Mb), "WorkingSetBytes": bounded(10*e2evolume.Kb, 80*e2evolume.Mb), "RSSBytes":        bounded(1*e2evolume.Kb, 80*e2evolume.Mb), <del> "PageFaults":      bounded(0, 1000000), "MajorPageFaults": bounded(0, 10), </del> <ins> "PageFaults":      bounded(0, expectedPageFaultsUpperBound), "MajorPageFaults": bounded(0, expectedMajorPageFaultsUpperBound), </ins> }), "VolumeStats": gstruct.MatchAllElements(summaryObjectID, gstruct.Elements{ "test-empty-dir": gstruct.MatchAllFields(gstruct.Fields{
Change:
google protobuf repository has moved from old location pointing currently to Point scripts to the new location ,kubernetes-csi/csi-lib-utils,kubernetes/kubernetes N/A Kubernetes version (use ): 1.21 Cloud provider or hardware configuration: N/A OS (e.g: ): Mac OS Kernel (e.g. ): Darwin Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
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
FYI
/assign
/area code-organization /kind cleanup

Discussion:
echo "Generating protobuf requires protoc 3.0.0-beta1 or newer. Please download and" echo "install the platform appropriate Protobuf package for your OS: " echo <del> echo "  https://github.com/google/protobuf/releases" </del> <ins> echo "  https://github.com/protocolbuffers/protobuf/releases" </ins> echo echo "WARNING: Protobuf changes are not being validated" exit 1
Change:
pull-kubernetes-unit TestVolumeUnmountAndDetachControllerDisabled It failed on but after that the test is passing DATA RACE It seems that the data race is caused by below code It failing of test is Flaky, it was not reproducible on my local machine too, I have used below command to run the test output on my local machine I would like to work on this issue, is it possible to reproduce this issue locally?
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
SIG Testing owns test frameworks, CI infrastructure, and other things to support testing. But this test is owned by SIG storage I believe since it tests their code, as we own tests that test our code.

Discussion:
1 /* expectedSetUpCallCount */, testKubelet.volumePlugin)) // Remove pod <del> // TODO: this may not be threadsafe (technically waitForVolumeUnmount) kubelet.podWorkers.(*fakePodWorkers).removeRuntime = map[types.UID]bool{pod.UID: true} </del> <ins> // TODO: technically waitForVolumeUnmount kubelet.podWorkers.(*fakePodWorkers).setPodRuntimeBeRemoved(pod.UID) </ins> kubelet.podManager.SetPods([]*v1.Pod{}) assert.NoError(t, kubelet.volumeManager.WaitForUnmount(pod))

1 /* expectedSetUpCallCount */, testKubelet.volumePlugin)) // Remove pod <del> kubelet.podWorkers.(*fakePodWorkers).removeRuntime = map[types.UID]bool{pod.UID: true} </del> <ins> kubelet.podWorkers.(*fakePodWorkers).setPodRuntimeBeRemoved(pod.UID) </ins> kubelet.podManager.SetPods([]*v1.Pod{}) assert.NoError(t, waitForVolumeUnmount(kubelet.volumeManager, pod))

defer f.statusLock.Unlock() return f.removeRuntime[uid] } <ins> func (f *fakePodWorkers) setPodRuntimeBeRemoved(uid types.UID) { f.statusLock.Lock() defer f.statusLock.Unlock() f.removeRuntime = map[types.UID]bool{uid: true} } </ins> func (f *fakePodWorkers) ShouldPodContentBeRemoved(uid types.UID) bool { f.statusLock.Lock() defer f.statusLock.Unlock()
Change:
does not explicitly mention that buildx cli plugin is required for this operation. If buildx is not present, running gives the following error (which is not very helpful.) Running the manual command also results in the same error. I think that the doc should mention that buildx cli plugin should be present for the Docker Image to successfully build, how users can check if buildx is installed, and if not already present. (I'm very new to kubernetes community, and I spent 2-3 days trying to figure this out, so this could really help beginners who get stuck here).
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 contributor-experience
/kind documentation
this seems like a valid improvement. if someone wants to take this, PRs are welcome. EDIT: it seems the buildx cli plugin installation is a bit vague on the side of docker too. thus i will not add the label.
Happy to help here Docker Buildx installation can be verified by checking if file is present in . Buildx can be installed by the following sequence of commands (): Also, should this issue be left open for community (such as first time contributors) or should I make the changes and raise a PR (if we need it quickly)?
if you think you can make the change, please go ahead. thanks

Discussion:
**Note**: You will want to set the Docker VM to have at least 8GB of initial memory or building will likely fail. (See: [#11852]( http://issue.k8s.io/11852)). * **Linux with local Docker**  Install Docker according to the [instructions](https://docs.docker.com/installation/#installation) for your OS. * **Windows with Docker Desktop WSL2 backend**  Install Docker according to the [instructions](https://docs.docker.com/docker-for-windows/wsl-tech-preview/). Be sure to store your sources in the local Linux file system, not the Windows remote mount at `/mnt/c`. <del> **Note**: You will need to check if Docker CLI plugin buildx is properly installed. You can install buildx according to the [instructions](https://github.com/docker/buildx/blob/master/README.md#installing). </del> <ins> **Note**: You will need to check if Docker CLI plugin buildx is properly installed (`docker-buildx` file should be present in `~/.docker/cli-plugins`). You can install buildx according to the [instructions](https://github.com/docker/buildx/blob/master/README.md#installing). </ins> 2. **Optional** [Google Cloud SDK](https://developers.google.com/cloud/sdk/) You must install and configure Google Cloud SDK if you want to upload your release to Google Cloud Storage and may safely omit this otherwise.
Change:
<!-- 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 --A kube-apiserver does not support all of the signing algorithms listed in RFC 7518 It fails with something like When looking into the or in the code I really get the impression that all algorithms from the RFC document are supported But after some time, I noticed the most essential word is : The documentation to be improved to explicitly list the supported algorithms instead of referring to the RFC document that lists much more algorithms than the actual supported ones. Run the kube-apiserver with flag I think the really supported algorithms are explicitly listed here Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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 auth /kind documentation
: I will be happy to do it, but would require some more insight on what is to be done?
Hi Could you please elaborate what is not clear? I think I have provided quite detailed information and references to the code and documentation. Just to be clear, the documentation is correct even today, but it is hard to digest as the referenced RFC document does not describe which signing algorithm is asymmetric and which symmetric.
Hi IMO We can do two things here either we will mention the supported signing algorithm for oidc instead of or explicitly mention the supported signing algorithm in the docs. What do you suggest? I'm up for it if nobody is doing that.
Fixed it here:

Discussion:
fs.StringSliceVar(&o.OIDC.SigningAlgs, "oidc-signing-algs", []string{"RS256"}, ""+ "Comma-separated list of allowed JOSE asymmetric signing algorithms. JWTs with a "+ <del> "'alg' header value not in this list will be rejected. "+ </del> <ins> "supported 'alg' header values are: RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512. "+ </ins> "Values are defined by RFC 7518 https://tools.ietf.org/html/rfc7518#section-3.1.") fs.Var(cliflag.NewMapStringStringNoSplit(&o.OIDC.RequiredClaims), "oidc-required-claim", ""+