Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add e2e test for cronjob chained removal #48068

Merged
merged 2 commits into from
Aug 8, 2017

Conversation

soltysh
Copy link
Contributor

@soltysh soltysh commented Jun 26, 2017

This is test proving #44058 works with cronjobs. This will fail until the aforementioned PR merges.

@caesarxuchao ptal

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Jun 26, 2017
@soltysh soltysh added this to the v1.7 milestone Jun 26, 2017
@k8s-github-robot k8s-github-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. release-note-label-needed labels Jun 26, 2017
@soltysh soltysh force-pushed the cronjob_removal_e2e branch from 018caa2 to 19dbefd Compare June 26, 2017 14:35
@k8s-github-robot k8s-github-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 26, 2017
@soltysh soltysh added release-note-none Denotes a PR that doesn't merit a release note. and removed release-note-label-needed labels Jun 26, 2017
@soltysh soltysh assigned caesarxuchao and unassigned madhusudancs and bowei Jun 26, 2017
@@ -75,6 +75,13 @@ var _ = framework.KubeDescribe("CronJob", func() {
By("Removing cronjob")
err = deleteCronJob(f.ClientSet, f.Namespace.Name, cronJob.Name)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

deleteCronJob is not setting any DeleteOptions and the default REST strategy for CJs is orphaning so I am wondering how does this test work?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you need to set the policy to DeletePropagationBackground.

@0xmichalis
Copy link
Contributor

0xmichalis commented Jun 26, 2017

Unless you are doing a foreground deletion, this test is not going to be stable. Also can you verify that the CronJob is deleted?

@@ -75,6 +75,13 @@ var _ = framework.KubeDescribe("CronJob", func() {
By("Removing cronjob")
err = deleteCronJob(f.ClientSet, f.Namespace.Name, cronJob.Name)
Expect(err).NotTo(HaveOccurred())
By("Ensuring cronjob does not leave jobs nor pods behind")
jobs, err = f.ClientSet.Batch().Jobs(f.Namespace.Name).List(metav1.ListOptions{})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be a poll and list. The GC takes time.

jobs, err = f.ClientSet.Batch().Jobs(f.Namespace.Name).List(metav1.ListOptions{})
Expect(err).NotTo(HaveOccurred())
Expect(jobs.Items).To(HaveLen(0))
pods, err := f.ClientSet.Core().Pods(f.Namespace.Name).List(metav1.ListOptions{})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here.

@caesarxuchao
Copy link
Member

@Kargakis @soltysh we need to reach consensus on whether to use foreground or background GC.

I think in this test, the stable way is using the foreground gc, then polls for the final deletion of the cronjob, and then verify the pods are deleted.

I think @soltysh's intention was to test the GC properly cascades the background GC. For that, i think it is worth a separate test.

@0xmichalis
Copy link
Contributor

@caesarxuchao should we need to poll in case of foreground deletion? IIUC, the DELETE call should block until everything is deleted, isn't that the case?

@soltysh
Copy link
Contributor Author

soltysh commented Jun 27, 2017

@Kargakis based on this I'm assuming the blocking depends what we set in ownerRef. cronjob has that set so I'll go with foreground deletion as proposed by @caesarxuchao

@soltysh
Copy link
Contributor Author

soltysh commented Jun 27, 2017

@Kargakis actually, the foreground removal works without the fix, so we need background removal to verify its role.

@soltysh soltysh force-pushed the cronjob_removal_e2e branch from 19dbefd to f9d135a Compare June 27, 2017 14:18
@k8s-github-robot k8s-github-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. labels Jun 27, 2017
@soltysh
Copy link
Contributor Author

soltysh commented Jun 27, 2017

@caesarxuchao @Kargakis I've created a separate tests just for cronjobs GC, ptal

@soltysh
Copy link
Contributor Author

soltysh commented Jun 28, 2017

@caesarxuchao any objections to merge this in?

}

By("Delete the cronjob")
if err := f.ClientSet.BatchV2alpha1().CronJobs(f.Namespace.Name).Delete(cronJob.Name, getNonOrphanOptions()); err != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be fixed in another PR. OrphanDependents field is deprecated, set propagationPolicy to Background instead.

_, err := f.ClientSet.BatchV2alpha1().CronJobs(f.Namespace.Name).Get(cronJob.Name, metav1.GetOptions{})
return err != nil && !errors.IsNotFound(err), nil
})
By("Verify if cronjob does not leave jobs nor pods behind")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should be wrapped in a poll. The Cronjob is deleted with getNonOrphanOptions, which is equivalent of the "background" GC policy, which causes the cronjob to be deleted immediately, then GC deletes the dependents in the background.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you use the "foreground" GC, then GC will delete the cronjob after all dependents are deleted, then these checks make sense.

@caesarxuchao caesarxuchao modified the milestones: v1.7, v1.8 Jun 29, 2017
@caesarxuchao
Copy link
Member

@soltysh too late for 1.7, changed to 1.8

@soltysh soltysh force-pushed the cronjob_removal_e2e branch from f9d135a to e0e8f29 Compare June 29, 2017 11:44
@k8s-github-robot k8s-github-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jun 29, 2017
@soltysh
Copy link
Contributor Author

soltysh commented Jun 29, 2017

@caesarxuchao I've updated per your suggestion and I've also split the fix to rs and deployment test swallowing errors to a separate commit.

@k8s-github-robot k8s-github-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 18, 2017
@caesarxuchao
Copy link
Member

/lgtm

@soltysh could you rebase? Thanks.

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 19, 2017
@k8s-github-robot
Copy link

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: caesarxuchao, soltysh

No associated issue. Update pull-request body to add a reference to an issue, or get approval with /approve no-issue

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@soltysh soltysh force-pushed the cronjob_removal_e2e branch from e0e8f29 to 591db87 Compare August 1, 2017 13:54
@soltysh
Copy link
Contributor Author

soltysh commented Aug 1, 2017

@caesarxuchao sorry, I was out for almost a month. I've rebased and addressed that single comment of yours. ptal

@k8s-github-robot k8s-github-robot removed lgtm "Looks good to me", indicates that a PR is ready to be merged. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Aug 1, 2017
@soltysh soltysh force-pushed the cronjob_removal_e2e branch from 591db87 to 17f8c97 Compare August 4, 2017 14:03
@soltysh
Copy link
Contributor Author

soltysh commented Aug 4, 2017

Bazel fixed, should be good now.

@soltysh
Copy link
Contributor Author

soltysh commented Aug 8, 2017

Based on previous approval I'm re-adding the labels.

@soltysh soltysh added approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm "Looks good to me", indicates that a PR is ready to be merged. labels Aug 8, 2017
@k8s-github-robot
Copy link

/test all [submit-queue is verifying that this PR is safe to merge]

@k8s-github-robot
Copy link

Automatic merge from submit-queue

@k8s-github-robot k8s-github-robot merged commit 6b529fb into kubernetes:master Aug 8, 2017
@soltysh soltysh deleted the cronjob_removal_e2e branch August 8, 2017 12:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note-none Denotes a PR that doesn't merit a release note. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants