jiebi/CodeConvo huggingface dataset:
Change:
} t.Run(gvk.String(), func(t *testing.T) { <del> for i := 0; i < 50; i++ { </del> <ins> for i := 0; i < 3; i++ { </ins> item := fuzzObject(t, gvk) builder := applyconfigurations.ForKind(gvk) jsonRoundTripApplyConfiguration(t, item, builder)

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 --pull-kubernetes-unit Two new tests were just in that take significant amounts of time in CI: ~These tests also appear to be flaking regularly: /assign
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
Related: At some point we should probably adjust the timeout. I'd like to get CI to a point where it uses whatever the default is in make test.
yes.
This loops each type 50 times, I'll drop that down to say, 3 times. We honestly don't need to fuzz these that hard, they typically catch problems quick.
The failures I see in gubernator shouldn't happen now that the PR is merged. Before myPR to add this test was merged, other PRs that fields (NamespaceSelector) would cause myPR's unit tests to fail and I would need to rebase it and run . Now that it is merged, will be run by the PR author that adds a field to a type to keep code in sync.
ah, so these failures on other PRs mean they needed to regen?
Yeah, the first one adds and the fuzzer detected the apply config builder had not been regenerated by . The others have field changes too.
ok, so it's noise for PRs in progress but not flakes. looks like the runtime/timeout issue is the only flake, which you can drop iterations significantly to solve
50-3 seems like it should get us to 10-15s total for both new tests
Change:
imageutils.GetE2EImage(imageutils.TestWebserver), imageutils.GetE2EImage(imageutils.VolumeNFSServer), imageutils.GetE2EImage(imageutils.VolumeGlusterServer), <ins> imageutils.GetE2EImage(imageutils.NonRoot), </ins> ) type testImagesStruct struct {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-node-kubelet-orphans Which test(s) are failing: [] Security Context should run with an image specified user ID [It] [] Security Context When creating a container with runAsNonRoot should not run with an explicit root user ID [LinuxOnly] [It] Since when has it been failing: Testgrid link: Reason for failure: "" is not in the white list Anything else we need to know:
/area test /sig node
Change:
fi } <ins> # Deletes a security group # usage: delete_security_group <sgid> function delete_security_group { local -r sg_id=${1} echo "Deleting security group: ${sg_id}" # We retry in case there's a dependent resource - typically an ELB n=0 until [ $n -ge 20 ]; do $AWS_CMD delete-security-group --group-id ${sg_id} > $LOG && return n=$[$n+1] sleep 3 done echo "Unable to delete security group: ${sg_id}" exit 1 } </ins> function ssh-key-setup { if [[ ! -f "$AWS_SSH_KEY" ]]; then ssh-keygen -f "$AWS_SSH_KEY" -N ''

Discussion:
See example log below. I'm pretty sure the SG in question was from an ELB, but we should just auto-retry anyway.
Change:
configs[APIServer] = Config{e2eRegistry, "sample-apiserver", "1.17"} configs[AppArmorLoader] = Config{e2eRegistry, "apparmor-loader", "1.0"} configs[BusyBox] = Config{dockerLibraryRegistry, "busybox", "1.29"} <del> configs[CheckMetadataConcealment] = Config{e2eRegistry, "metadata-concealment", "1.2"} </del> <ins> configs[CheckMetadataConcealment] = Config{promoterE2eRegistry, "metadata-concealment", "1.6"} </ins> configs[CudaVectorAdd] = Config{e2eRegistry, "cuda-vector-add", "1.0"} configs[CudaVectorAdd2] = Config{e2eRegistry, "cuda-vector-add", "2.0"} configs[DebianIptables] = Config{buildImageRegistry, "debian-iptables", "buster-v1.3.0"}

Discussion:
Warning: The v0.1 and v1beta1 metadata server endpoints are deprecated and scheduled for shutdown on September 30, 2020. This test (which runs in most e2e jobs that run on GCE): Schedules a container that runs this: Resulting in a number of legacy metadata endpoints getting hit. To see if this test is going to start failing across all release branches on Sep 30th, we could try disabling the endpoints ahead of time via: In fact and support for expecting different results based on whether is set. My concern is the test expects 200 for some root endpoints, and 403 for disabled endpoints. However the e-mail I received as a GCP customer tells me any legacy endpoints may return 404. I'm inclined to suggest we remove the legacy endpoints from the check, bump the image version, and cherry-pick use of the new image version back to all release-branches. WDYT since you were involved with the earlier PRs /sig auth /sig cloud-provider /provider gcp /sig testing /priority important-soon (I'm tempted to critical-urgent this but it's not drop-everything yet) /milestone v1.20
/kind cleanup
Heyho I wanted to check how it is going? The code freeze is starting 12.11.2020 (about 3-4 weeks from now) and while there is still plenty of time, we want to ensure that each relevant issue has a chance to be considered. As the issue is tagged for 1.20, is it still planned for this release?
Bug Triage here, we're pretty late into code freeze and it doesn't look like there has been much activity recently. I am going to clear the milestone on this issue. /milestone clear
any update here?
Try to cleanup the legacy endpoints in
/milestone v1.21
/reopen This needs to stay open until the new image has been verified to work and has been promoted (ref: )
Reopened this issue. <detailsIn response to : /reopen This needs to stay open until the new image has been verified to work and has been promoted (ref: ) 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
/triage accepted /assign
Change:
driverNodeID, maxVolumePerNode, accessibleTopology, err := csi.NodeGetInfo(ctx) if err != nil { <del> klog.Error(log("registrationHandler.RegisterPlugin failed at CSI.NodeGetInfo: %v", err)) </del> if unregErr := unregisterDriver(pluginName); unregErr != nil { klog.Error(log("registrationHandler.RegisterPlugin failed to unregister plugin due to previous error: %v", unregErr)) <del> return unregErr </del> } return err } err = nim.InstallCSIDriver(pluginName, driverNodeID, maxVolumePerNode, accessibleTopology) if err != nil { <del> klog.Error(log("registrationHandler.RegisterPlugin failed at AddNodeInfo: %v", err)) </del> if unregErr := unregisterDriver(pluginName); unregErr != nil { klog.Error(log("registrationHandler.RegisterPlugin failed to unregister plugin due to previous error: %v", unregErr)) <del> return unregErr </del> } return err }

Discussion:
What happened: We currently unregister the CSI driver if an error happens while registering it. Then, if another error happens, we return only the unregistration error. The problem is that the user will only see the unregistration error if they check the registrar logs. This gives the impression that it never tried to register the driver. What you expected to happen: The user should see the registration error instead. How to reproduce it (as minimally and precisely as possible): Try to install a CSI driver in a cluster where CSINodeInfo and/or CSIDriver CRDs are not created. Check registrar logs /kind bug /sig storage CC
/assign
Change:
newPodPreset := obj.(*settings.PodPreset) oldPodPreset := old.(*settings.PodPreset) <ins> pod.DropDisabledVolumeMountsAlphaFields(oldPodPreset.Spec.VolumeMounts) pod.DropDisabledVolumeMountsAlphaFields(newPodPreset.Spec.VolumeMounts) </ins> // Update is not allowed newPodPreset.Spec = oldPodPreset.Spec }

Discussion:
says "Before persisting the object to storage, clear disabled alpha fields". There is that actually implements it but there are some discussions about it. This issues is a reminder that introduced by needs to be cleared too when the discussion in settles down. /assign
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
kind/cleanup priority/important-soon
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/api-machinery: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
Change:
# Admission Controllers to invoke prior to persisting objects in cluster ENABLE_ADMISSION_PLUGINS="LimitRanger,ResourceQuota" <del> DISABLE_ADMISSION_PLUGINS="ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,StorageObjectInUseProtection" </del> <ins> DISABLE_ADMISSION_PLUGINS="ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,StorageObjectInUseProtection" </ins> # Include RBAC (to exercise bootstrapping), and AlwaysAllow to allow all actions AUTHORIZATION_MODE="RBAC,AlwaysAllow"

Discussion:
In 1.30, the PersistentVolumeLabel admission plugin blocks creation of in-tree AzureDisk and vSphere PVs: The reason is that the cloud provider was removed (), but the admission plugin still calls GetCloudProvider there, which fails: The PV should be admitted + created. Enable PersistentVolumeLabel admission plugin. For example, when running local-up- Create AzureDisk PV on any 1.30 cluster, you don't need Azure cloud: /sig storage /priority important-soon <detailsToday's master </details<detailsAzure </detailsNo response <detailslocal-up- </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
I am fixing the worst bug in and I plan to backport it to 1.30. However, we should consider removing the whole PersistentVolumeLabel admission plugin. Most of the cloud providers were removed, only GCE remains and IMO even that one will be removed sooner or later. The admission plugin has no way to get volume zone + region and is therefore useless. The admission said (in 1.26, where we had all in-tree cloud providers): Such webhook never materialized for AWS, Azure nor vSphere and I am not aware of any plans for GCE.
It did materialize in So removing it from k/k is the best way forward.
Change:
}) expectNoError(err) defer c.Pods(ns).Delete(labelPodName, api.NewDeleteOptions(0)) <del> expectNoError(waitForPodRunningInNamespace(c, labelPodName, ns)) </del> <ins> // check that pod got scheduled. We intentionally DO NOT check that the // pod is running because this will create a race condition with the // kubelet and the scheduler: the scheduler might have scheduled a pod // already when the kubelet does not know about its new label yet. The // kubelet will then refuse to launch the pod. expectNoError(waitForPodNotPending(c, ns, labelPodName)) </ins> labelPod, err := c.Pods(ns).Get(labelPodName) expectNoError(err) Expect(labelPod.Spec.NodeName).To(Equal(nodeName))

Discussion:
Jenkins project kubernetes-e2e-gke-ci build: One more flakiness blocks entire submit queue.
cc/
Looking into this.
do you have a longer test trace for me? I cannot see much that could be flaky due to the tests. It just does this: start pod without-label remember NodeName delete without-label set label <some-uuid=42 on NodeName launch pod with-label and NodeSelector set to {"": nodeName, <some-uuid":42} The only idea I have is that the patch command does not work reliably (assuming that the NodeSelector support in the scheduler works and is not flaky itself):
here is the most recent failure from our Jenkins build:
thanks for the logs. This clarifies what happens: the kubelet does not know its new labels. Maybe, its node storage didn't update fast enough and there is a race with the scheduler:
This might be fixed with .
Change:
detect-project echo "Bringing down cluster" <ins> set +e  # Do not stop on error </ins> <del> gcloud preview managed-instance-groups --zone "${ZONE}" delete  </del> <ins> # The gcloud APIs don't return machine parsable error codes/retry information. Therefore the best we can # do is parse the output and special case particular responses we are interested in. deleteCmdOutput=$(gcloud preview managed-instance-groups --zone "${ZONE}" delete  </ins> --project "${PROJECT}"  --quiet  <del> "${NODE_INSTANCE_PREFIX}-group" || true </del> <ins> "${NODE_INSTANCE_PREFIX}-group") if [[ "$deleteCmdOutput" != ""  ]]; then # Managed instance group deletion is done asyncronously, we must wait for it to complete, or subsequent steps fail deleteCmdOperationId=$(echo $deleteCmdOutput | grep "Operation:" | sed "s/.*Operation:s//" | sed "s/s.*//" | sed "s/ //g") if [[ "$deleteCmdOperationId" != ""  ]]; then deleteCmdStatus="PENDING" while [[ "$deleteCmdStatus" != "DONE" ]] do sleep 5 deleteCmdOperationOutput=$(gcloud preview managed-instance-groups --zone "${ZONE}" get-operation $deleteCmdOperationId) deleteCmdStatus=$(echo $deleteCmdOperationOutput | grep -i "status:" | sed "s/.*status:s//" | sed "s/s.*//" | sed "s/ //g") echo "Waiting for MIG deletion to complete. Current status: " $deleteCmdStatus done fi fi </ins> gcloud compute instance-templates delete  --project "${PROJECT}"  --quiet  <del> "${NODE_INSTANCE_PREFIX}-template" || true </del> <ins> "${NODE_INSTANCE_PREFIX}-template" </ins> # First delete the master (if it exists). gcloud compute instances delete 

Discussion:
'kubernetes-soak-weekly-deploy' sometimes fails to deploy because the clean-up cluster step fails to delete the template: Then the subsequent cluster step fails to create the template, because it already exists: It keeps retrying and failing, because the template already exists, until it times out and the deployment fails. Suggested fixes: Cluster down should try harder to delete the template (maybe wait/retry). Cluster up should recognize that the template exists, and try to delete/recreate, or just re-use the existing.
Looks like ran in to this on Monday, May 11, 2015 around 1:00 PM PST. I'll assign this to my self and take a crack at fixing it.
This is causing most of our e2e tests to fail in continuous integration as well as users private e2e test clusters. Bumping to priority/p0 and v1.0 milestone. Saad thinks he's figured it out, and is working on a fix as we speak.
In essence... Saad: "I think what's happening is the previous clean up step to delete the managed instance group happens asynchronously, therefore there is a race condition to delete the template. Working on a fix".
Change:
<ins> # See the OWNERS docs at https://go.k8s.io/owners approvers: - sig-scheduling-maintainers reviewers: - sig-scheduling labels: - sig/scheduling </ins>

Discussion:
/kind cleanup /kind documentation /sig scheduling /sig node /sig apps The ownership of controller/nodelifecycle is unclear. The currently has some individual names and no labels, although it gets a sig/apps label from the parent pkg/controller OWNERS. This controller has the following functionality: Add taints based on health of the node (from conditions) Evict Pods based on NoExecute taints. The candidates for long term ownership are: : The ones who introduced it and overall maintain taints and tolerations. : Because it's called "node lifecycle", although this could be a misnomer. : Due to implications to the lifecycle of applications and because they are the main shepherds of kcm. I think it makes the most sense under scheduling, but wanted to gather all stakeholder's feedback.
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 as original author
I think both scheduling and node can own it, if node is too overwhelmed, sig scheduling makes sense as a home.
Thanks, It would be nice to sort out the ownership. It sounds reasonable for sig-scheduling to own it. /cc
Outcome from SIG Scheduling meeting: As already identified, this controller actually has 2 functionalities. From a technical standpoint, the following ownership makes sense to SIG Scheduling leads: Setting taints based on Node conditions -SIG Node Evicting pods that don't tolerate NoExecute taints -SIG Scheduling This ownership structure can be set-up even before is implemented, as the taint functionality has its own folder. I'll create a PR based on the above. But and please raise any concerns.
+1 on this proposal.
+1 on the proposal - I believe if we were to assign responsibility to who owns node level invariants that apply to workloads, it would be sig-node (they generally own node + pod). pod-safety, for instance, I considered owned by sig-node even though it touches storage, apps, api-machinery, and scheduling because the node owns the pod at the time safety is imposed.
Change:
"testing" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/kubectl/cmd" </ins> ) <ins> func TestExtraArgsFail(t *testing.T) { buf := bytes.NewBuffer([]byte{}) f, _, _ := NewAPIFactory() c := f.NewCmdCreate(buf) if cmd.ValidateArgs(c, []string{"rc"}) == nil { t.Errorf("unexpected non-error") } } </ins> func TestCreateObject(t *testing.T) { _, _, rc := testData() rc.Items[0].Name = "redis-master-controller"

Discussion:
cc
When deleting/stopping using file, you don't specify resource (in this case 'pod'), as it's inferred from the file.
Thanks and sorry for confusion
Ok, but should not work as well.
Change:
return successfulDeletes, errorFromChannel(errCh) } <ins> func nonIgnoredFailedPodsCount(jobCtx *syncJobCtx, failedPods []*v1.Pod) int { result := len(failedPods) if feature.DefaultFeatureGate.Enabled(features.JobPodFailurePolicy) && jobCtx.job.Spec.PodFailurePolicy != nil { for _, p := range failedPods { _, countFailed, _ := matchPodFailurePolicy(jobCtx.job.Spec.PodFailurePolicy, p) if !countFailed { result-- } } } return result } </ins> // deleteJobPods deletes the pods, returns the number of successful removals // and any error. func (jm *Controller) deleteJobPods(ctx context.Context, job *batch.Job, jobKey string, pods []*v1.Pod) (int32, error) {

Discussion:
Pod backoff calculation excludes pods that match an rule in the failure policy: This could lead to fast retries, overwhelming the control plane, if most failures match an rule. The semantics of is not to count towards the limit, but the backoff should still be respected. /sig apps Recreations to be throttled. a Job with failure policy that matches every kind of failure. a container that always fails You would observe immediate recreation. No response_ 27+ <detailsN/A </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
cc
Change:
}) } <ins> func (e *eventBroadcasterImpl) Shutdown() { e.Broadcaster.Shutdown() } </ins> func recordToSink(sink EventSink, event *v1.Event, eventCorrelator *EventCorrelator, sleepDuration time.Duration) { // Make a copy before modification, because there could be multiple listeners. // Events are safe to copy like this.

Discussion:
In order to initialize a client-go , you need an . and friends initialize a new : launches a goroutine: This goroutine is stoppable with . However, the interface returned above does not expose anything that calls that shutdown method, AFAICT. This means that that goroutine cannot ever be cleaned up. That's not great. It's fine if you're using in like k/k does and never stopping anything, but if you ever want to stop your controllers and start up new ones, it becomes an issue. Tested/tracked down against master (as of ). /sig apimachinery /kind bug
The label(s) cannot be applied. These labels are supported: <detailsIn response to : In order to initialize a client-go , you need an . and friends initialize a new : /kind bug </details
/sig api-machinery I always forget the dash
Change:
resourceName: testCase.Name, resource:     testCase.Resource, } <del> body, err := ioutil.ReadAll(testCase.Res.Body) if err != nil { t.Errorf("failed to read body: %v", err) } _, _, err = r.transformResponse(testCase.Res, testCase.Req, body) </del> <ins> result := r.transformResponse(testCase.Res, testCase.Req) err := result.err </ins> if !testCase.ErrFn(err) { t.Errorf("unexpected error: %v", err) continue

Discussion:
Storing r.req / r.resp internally (for use from DoRaw and Do) is probably not the right factoring. There should be a common method doRaw that returns request and body.