jiebi/CodeConvo huggingface dataset:
Change:
# unit and integration tests FROM golang:1.4 <del> MAINTAINER  jeff lowdermilk <jeffml@google.com> </del> <ins> MAINTAINER  Jeff Lowdermilk <jeffml@google.com> </ins> ENV KUBE_TEST_API_VERSIONS  v1,extensions/v1beta1 ENV KUBE_TEST_ETCD_PREFIXES registry ENV WORKSPACE               /workspace <ins> ENV TERM                    xterm </ins> WORKDIR /workspace <del> ADD run.sh ./ </del> RUN apt-get -o Acquire::Check-Valid-Until=false update && apt-get install -y rsync <ins> RUN apt-get install -y file </ins> RUN mkdir -p /go/src/k8s.io/kubernetes RUN ln -s /go/src/k8s.io/kubernetes /workspace/kubernetes

Discussion:
In the pull request Jenkins, we're running up to 8 instances of verification checks, build, unit tests, integration tests, and e2e tests. Unfortunately, it seems like several of these components were not designed to run simultaneous to other tests on the same machine. In particular, several unit tests seem to write to static file names in /tmp (or equivalent), which is a fairly easy fix. Some of the verification checks and the integration test start up etcd, however, and the etcd helper checks that only a single etcd binary is running on the host (and uses a static port for it). For example: We might be able to fix the etcd issue separately, or we can just figure out how to containerize all of these tests so they can't possibly interfere with each other. Note that we're ignoring the exit status of the verification checks and unit/integration tests right now, so these etcd failures are effectively being ignored (though it is causing us to miss test coverage).
What percentage of tests are failing due to being non-hermetic like this?
I'm not sure about unit tests (I've anecdotally seen just a few fail), but the verification checks are failing fairly regularly, and the integration test is also similarly frequently not running due to this.
To be clear, I'm looking for real numbers, to decide whether it's feasible to temporarily disable a small number of tests until we can hermetify them. Otherwise we need to turn off all unit, integration and verification tests in Jenkins to avoid irritating invalid regression signals. We need to do one or the other this week.
I'll try to dig through the logs, figure out which ones have failed recently, disable them in Jenkins, and see whether the flakes abate.
I just turned off all unit, integration and verification checks in Jenkins, as a temporary measure to unstall the merge-bot.
As a point of information, I just found approximately 20 tests in which use a static tmp path with semi-random filenames which are highly likely to collide. We could keep searching for unit tests that are non-hermetic, but it'd probably be a better investment of time to fix the test infrastructure so test authors don't need to care (and so we don't need to go look at and fix ~2000 test cases).

Another few metrics, using the string "/tmp" as a likely anti-pattern: We'd need to update each of these 23 files to get them to use or if they aren't already.
Created to track cleaning up tempdir usage in unit tests.
cc
Change:
}) /* <del> Release: v1.17, v1.21 </del> <ins> Release: v1.17, v1.21, v1.27 </ins> Testname: aggregator-supports-the-sample-apiserver Description: Ensure that the sample-apiserver code from 1.17 and compiled against 1.17 will work on the current Aggregator/API-Server.

Discussion:
[X] Test approval issue: [X] Test PR: [x] Two weeks soak end date: [X] Test promotion PR: According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. Using a number of existing e2e test practices the has to cover the outstanding APIService endpoints. There has been some around how the current Conformance test is using RBAC, which is optional and not part of Conformance. Those calls will now only happen if is true. The e2e logs for this test are listed below.

This query shows the following APIService endpoints are hit within a short period of running this e2e test example endpoint | useragent ---------------------------------------------+
createApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1CollectionAPIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] listApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] (10 rows) If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
Change:
// TestPostFilterPlugin tests invocation of postfilter plugins. func TestPostFilterPlugin(t *testing.T) { <del> numNodes := 1 </del> <ins> var numNodes int32 = 1 </ins> tests := []struct { name                      string <del> numNodes                  int </del> <ins> numNodes                  int32 </ins> rejectFilter              bool failScore                 bool rejectPostFilter          bool <del> expectFilterNumCalled     int </del> <ins> expectFilterNumCalled     int32 </ins> expectScoreNumCalled      int32 expectPostFilterNumCalled int }{ { name:                      "Filter passed and Score success", <del> numNodes:                  3, </del> <ins> numNodes:                  30, </ins> rejectFilter:              false, failScore:                 false, rejectPostFilter:          false, <del> expectFilterNumCalled:     3, expectScoreNumCalled:      3, </del> <ins> expectFilterNumCalled:     30, expectScoreNumCalled:      30, </ins> expectPostFilterNumCalled: 0, }, {

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: integration-master Which test(s) are flaking: TestPostFilterPlugin Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/sig testing
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 /remove-sig testing
/assign
Change:
})) framework.Logf("Reconciled root ca configmap in namespace %q", f.Namespace.Name) }) <ins> ginkgo.It("should update a ServiceAccount", func() { saClient := f.ClientSet.CoreV1().ServiceAccounts(f.Namespace.Name) saName := "e2e-sa-" + utilrand.String(5) initialServiceAccount := &v1.ServiceAccount{ ObjectMeta: metav1.ObjectMeta{ Name: saName, }, AutomountServiceAccountToken: utilptr.Bool(false), } ginkgo.By(fmt.Sprintf("Creating ServiceAccount %q ", saName)) createdServiceAccount, err := saClient.Create(context.TODO(), initialServiceAccount, metav1.CreateOptions{}) framework.ExpectNoError(err) framework.ExpectEqual(createdServiceAccount.AutomountServiceAccountToken, utilptr.Bool(false), "Failed to set AutomountServiceAccountToken") framework.Logf("AutomountServiceAccountToken: %v", *createdServiceAccount.AutomountServiceAccountToken) ginkgo.By(fmt.Sprintf("Updating ServiceAccount %q ", saName)) var updatedServiceAccount *v1.ServiceAccount err = retry.RetryOnConflict(retry.DefaultRetry, func() error { updateServiceAccount, err := saClient.Get(context.TODO(), saName, metav1.GetOptions{}) framework.ExpectNoError(err, "Unable to get ServiceAccount %q", saName) updateServiceAccount.AutomountServiceAccountToken = utilptr.Bool(true) updatedServiceAccount, err = saClient.Update(context.TODO(), updateServiceAccount, metav1.UpdateOptions{}) return err }) framework.ExpectNoError(err, "Failed to update ServiceAccount") framework.ExpectEqual(updatedServiceAccount.AutomountServiceAccountToken, utilptr.Bool(true), "Failed to set AutomountServiceAccountToken") framework.Logf("AutomountServiceAccountToken: %v", *updatedServiceAccount.AutomountServiceAccountToken) }) </ins> }) var reportLogsParser = regexp.MustCompile("([a-zA-Z0-9-_]*)=([a-zA-Z0-9-_]*)$")

Discussion:
[X] Test approval issue: [X] Test PR: 5 Oct 2022 [X] Two weeks soak end date: 19 Oct 2022 [X] Test promotion PR: According to this APIsnoop query, there are still three remaining LimitRange endpoints which are untested. replaceCoreV1NamespacedServiceAccount Using a number of existing e2e test practices a new has been created for one ServiceAccount endpoint. The e2e logs for this test are listed below. This query shows which ServiceAccount 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 1 point 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
Change:
) // updateReplicaSetStatus attempts to update the Status.Replicas of the given ReplicaSet, with a single GET/PUT retry. <del> func updateReplicaSetStatus(c unversionedextensions.ReplicaSetInterface, rs *extensions.ReplicaSet, newStatus extensions.ReplicaSetStatus) (updateErr error) { </del> <ins> func updateReplicaSetStatus(c unversionedextensions.ReplicaSetInterface, rs *extensions.ReplicaSet, newStatus extensions.ReplicaSetStatus) (*extensions.ReplicaSet, error) { </ins> // This is the steady state. It happens when the ReplicaSet doesn't have any expectations, since // we do a periodic relist every 30s. If the generations differ but the replicas are // the same, a caller might've resized to the same replica count.

Discussion:
Is this a request for help? No. What keywords did you search in Kubernetes issues before filing this one? dangling ReplicaSet Is this a BUG REPORT or FEATURE REQUEST? BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Azure A1 OS (e.g. from /etc/os-release): NAME="Container Linux by CoreOS" ID=coreos VERSION=1235.9.0 VERSIONID=1235.9.0 BUILDID=2017-02-02-0235 PRETTYNAME="Container Linux by CoreOS 1235.9.0 (Ladybug)" ANSICOLOR="38;5;75" HOMEURL="" BUGREPORTURL="" Kernel (e.g. ): Linux node-3-vm 4.7.3-coreos-r2 SMP Thu Feb 2 02:26:10 UTC 2017 x8664 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools: own Others: What happened: Created new deployment by altering the image tag of the deployment descriptor and using kubectl apply -f "". Noticed that one container of the previous deployment stayed there. What you expected to happen: All containers from the previous deployment should have been terminated. How to reproduce it (as minimally and precisely as possible): I cannot reliably trigger this, I do several deployments per hour and sometimes this problem manifests itself. Anything else we need to know: Deployment descriptor:
Can you also post the output of kubectl get deployment tviftttapp -o yaml kubectl get rs (dangling rs) -o yaml When this manifests again?
Here are the current deployment, the dangling RS, and the "good" RS. Deployment: Dangling RS: Current RS:
It seems that status.availableReplicas for the new replica set is never correctly updated to 2. Short term if you stop using minReadySeconds (minReadySeconds=2 doesn't offer you much anyway), this problem should stop. Long term, we should fix the status update. cc:
can one of you guys paste logs from the controller manager when this issue occurs? Log level should be ideally set to 2.

I managed to reproduce it:
Will close this one once is cherry-picked into 1.5
4 is out and contains a fix that should force the Deployment to be resynced eventually and have availableReplicas updated. Not optimal yet but eventually consistent. I have queued up some follow-up work to refine the resync.
Does anyone know when version 1.5.4 OR 1.6 will be available using Redhat package downloads (in RPM form) ? I only see version 1.5.2 being the latest there. I have the same problem that is being discussed in this thread and want to upgrade so that my K8S cluster can support Deployments.
Change:
// 	    # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt" // 	    # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key" // 	networking: <del> // 	  serviceSubnet: "10.96.0.0/12" // 	  podSubnet: "10.100.0.1/24" </del> <ins> // 	  serviceSubnet: "10.96.0.0/16" // 	  podSubnet: "10.244.0.0/24" </ins> // 	  dnsDomain: "cluster.local" // 	kubernetesVersion: "v1.12.0" // 	controlPlaneEndpoint: "10.100.0.1:6443"

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 --I am trying to learn how to use kubeadm well and it looks like there may be a problem in the example configuration in . It says , but also uses address 10.100.0.1 for various host things like the kube-apiserver and the etcd server and the scheduler. Also, interestingly, it puts a different address --- 10.100.1.1 --- in the apiserver's cert SANs. I expected to not be confused. Kubernetes version (use ): 1.21.1 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
seems more like sig/cluster-lifecycle?
/area kubeadm
Sorry, typo, corrected.
But the 'bot does not seem to have noticed the edit.
/remove-sig multicluster
/sig cluster-lifecycle
yeah, FWIW commands are never evaluated on comment edit versus a new comment so that trivial edits do not e.g. restart tests etc. also no need to apologize! just trying to make sure things get the attention of the right folks. in particular seems to stay pretty on top of SCL/kubeadm issues
For the certs sans part, it seems to be intended as the comments above. For podSubnet and node Address overlap, it may be not suggested? Let me check.

Here is an example for dual-stack:
The podSubnet part in the dual stack example is suggested by in
he is right, the docs are wrong should be 10.100.0.0/24, but I think that is more an aesthetic issue, and the code will take the right subnet, but for docs is better to be pedantic yeah, that is why I always suggest to use subnets with more clear differentiation, 10.100.0.0/24 and 10.100.1.0/24 are easy to get wrong, however , 10.96.0.0/16 and 10.244.0.0/16 are not
Change:
pvcConditions := pvc.Status.Conditions Expect(len(pvcConditions)).To(Equal(0), "pvc should not have conditions") }) <ins> It("should allow expansion of block volumes", func() { pvc, storageClassVar, err = setupFunc(true /*allowExpansion*/, true /*blockVolume*/) By("Waiting for pvc to be in bound phase") pvcClaims := []*v1.PersistentVolumeClaim{pvc} pvs, err := framework.WaitForPVClaimBoundPhase(c, pvcClaims, framework.ClaimProvisionTimeout) framework.ExpectNoError(err, "Failed waiting for PVC to be bound %v", err) Expect(len(pvs)).To(Equal(1)) By("Expanding current pvc") newSize := resource.MustParse("6Gi") pvc, err = expandPVCSize(pvc, newSize, c) framework.ExpectNoError(err, "While updating pvc for more size") Expect(pvc).NotTo(BeNil()) pvcSize := pvc.Spec.Resources.Requests[v1.ResourceStorage] if pvcSize.Cmp(newSize) != 0 { framework.Failf("error updating pvc size %q", pvc.Name) } By("Waiting for cloudprovider resize to finish") err = waitForControllerVolumeResize(pvc, c, totalResizeWaitPeriod) framework.ExpectNoError(err, "While waiting for pvc resize to finish") By("Waiting for file system resize to finish") pvc, err = waitForFSResize(pvc, c) framework.ExpectNoError(err, "while waiting for fs resize to finish") pvcConditions := pvc.Status.Conditions Expect(len(pvcConditions)).To(Equal(0), "pvc should not have conditions") }) </ins> }) func createStorageClass(t testsuites.StorageClassTest, ns string, suffix string, c clientset.Interface) (*storage.StorageClass, error) {

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: I created a block EBS volume using dynamic provisioning. Then I resized the volume from 10GB to 20 GB. Both PV and block volume reflects the change, but the PVC's capacity is still 10GB. This could be caused by in-tree resize put the PVC condition under state, but no one is acting on the condition since it is block volume: /cc /sig storage What you expected to happen: PVC's capacity should be updated to 20GB How to reproduce it (as minimally and precisely as possible): Easy to reproduce using following specs: StorageClass: Claim: Pod: Anything else we need to know?: This will affect whether CSI migration should handle migration scenario for block volume resizing. Environment: Kubernetes version (use ):1.13 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: kops Network plugin and version (if this is a network-related bug): Others:
/sig aws
/assign
Change:
h := w.Header() // trigger the timeout cancel() <del> // mutate response Headers for j := 0; j < 1000; j++ { h.Set("Test", "post") </del> <ins> // keep mutating response Headers until the request times out for { select { case <-postTimeoutCh: return default: h.Set("Test", "post") } </ins> } }), func(req *http.Request) (*http.Request, bool, func(), *apierrors.StatusError) { <del> return req, false, func() {}, apierrors.NewServerTimeout(schema.GroupResource{Group: "foo", Resource: "bar"}, "get", 0) </del> <ins> return req, false, func() { close(postTimeoutCh) }, apierrors.NewServerTimeout(schema.GroupResource{Group: "foo", Resource: "bar"}, "get", 0) </ins> }, ), ),

Discussion:
Unit test in package flakes there is a race condition between the go routine that executes the request handler and the timeout go routine that waits for the handler to finish /sig api-machinery
/assign
I have a PR in the works
should fix it, I can easily reproduce it with the PR, the flake is not reproducible any more cc
/triage accepted
Change:
}) } <ins> func describeContainers(containers []api.ContainerStatus, out io.Writer) { for _, container := range containers { fmt.Fprintf(out, "  %v:n", container.Name) fmt.Fprintf(out, "    Image:t%sn", container.Image) switch { case container.State.Running != nil: fmt.Fprintf(out, "    State:tRunningn") fmt.Fprintf(out, "      Started:t%vn", container.State.Running.StartedAt.Time.Format(time.RFC1123Z)) case container.State.Waiting != nil: fmt.Fprintf(out, "    State:tWaitingn") if container.State.Waiting.Reason != "" { fmt.Fprintf(out, "      Reason:t%sn", container.State.Waiting.Reason) } case container.State.Termination != nil: fmt.Fprintf(out, "    State:tTerminatedn") if container.State.Termination.Reason != "" { fmt.Fprintf(out, "      Reason:t%sn", container.State.Termination.Reason) } if container.State.Termination.Message != "" { fmt.Fprintf(out, "      Message:t%sn", container.State.Termination.Message) } fmt.Fprintf(out, "      Exit Code:t%dn", container.State.Termination.ExitCode) if container.State.Termination.Signal > 0 { fmt.Fprintf(out, "      Signal:t%dn", container.State.Termination.Signal) } fmt.Fprintf(out, "      Started:t%sn", container.State.Termination.StartedAt.Time.Format(time.RFC1123Z)) fmt.Fprintf(out, "      Finished:t%sn", container.State.Termination.FinishedAt.Time.Format(time.RFC1123Z)) default: fmt.Fprintf(out, "    State:tWaitingn") } fmt.Fprintf(out, "    Ready:t%vn", printBool(container.Ready)) fmt.Fprintf(out, "    Restart Count:t%dn", container.RestartCount) } } func printBool(value bool) string { if value { return "True" } return "False" } </ins> // ReplicationControllerDescriber generates information about a replication controller // and the pods it has created. type ReplicationControllerDescriber struct {

Discussion:
Kubectl describe pods id only has top level pod information, without any information related to containers. Taking kube-dns pod as an example, which has 3 containers specified: If a pod with RestartAlways policy, but all contianers are in crashloop, the user cannot interpret the true state based on above information. Proposed to include ContainerStatus here.
Why isn't this redundant with ?
is for kubectl get pods id.
Change:
attribute.Stringer("accept", &lazyAccept{req: req}), attribute.Stringer("audit-id", &lazyAuditID{req: req}), attribute.Stringer("client", &lazyClientIP{req: req}), <ins> attribute.Stringer("api-group", &lazyAPIGroup{req: req}), attribute.Stringer("api-version", &lazyAPIVersion{req: req}), attribute.Stringer("name", &lazyName{req: req}), attribute.Stringer("subresource", &lazySubresource{req: req}), attribute.Stringer("namespace", &lazyNamespace{req: req}), </ins> attribute.String("protocol", req.Proto), attribute.Stringer("resource", &lazyResource{req: req}), attribute.Stringer("scope", &lazyScope{req: req}),

Discussion:
Feedback originally provided on slack: It would be helpful to have additional fields on APIServer spans. This is the current set of attributes we provide: It would be helpful to add: group, version, namespace, name, and subresource, if possible. Part of
/sig instrumentation /sig apimachinery /priority important-longterm cc /triage accepted
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig instrumentation /sig apimachinery /priority important-longterm cc /triage accepted 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 api-machinery
/assign
Change:
fmt.Fprintf(out, "%sn", r.Name) return nil }) <ins> checkErr(err) </ins> if found == 0 { <del> glog.V(2).Infof("No resource(s) found") </del> <ins> fmt.Fprintf(cmd.Out(), "No resources foundn") </ins> } }, }

Discussion:
We should support multiple objects on the command line, but, failing that, some kind of error message would be useful. /cc
Fixing, just fixed the equiv in create