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

Scheduledjob e2e #26027

Merged
merged 4 commits into from
Aug 12, 2016
Merged

Scheduledjob e2e #26027

merged 4 commits into from
Aug 12, 2016

Conversation

soltysh
Copy link
Contributor

@soltysh soltysh commented May 21, 2016

@erictune last element of the scheduledjob puzzle. I think we'll iterate on this once we have all the puzzles in place. This is one of those things that will be allowed to merge after code freeze.

* Introducing ScheduledJobs as described in [the proposal](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/scheduledjob.md) as part of `batch/v2alpha1` version (experimental feature).

Analytics


This change is Reviewable

@k8s-github-robot k8s-github-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/new-api size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels May 21, 2016
err = waitForActiveJobs(f.Client, f.Namespace.Name, scheduledJob.Name, 2)
Expect(err).NotTo(HaveOccurred())

By("Removing scheduledjob")
Copy link
Member

Choose a reason for hiding this comment

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

Should deleting a scheduledJob delete its jobs?

Copy link
Contributor Author

@soltysh soltysh May 23, 2016

Choose a reason for hiding this comment

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

Hmmm... that's something I wasn't sure about, either. With current approach I've decided that at least removing the SJ will not schedule more jobs, especially that the schedule is pretty dense (new job every 5 sec.). The question is do we care about the jobs after the SJ is removed? I'm inclined to say no. Lemme check how deployments treat older RS, if removing those will also remove them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From my quick skim over the DeploymentReaper it looks like it removes all related ReplicaSets. In that case I'd say yes remove all.

@soltysh
Copy link
Contributor Author

soltysh commented May 24, 2016

This is blocked by #25952.

@janetkuo
Copy link
Member

janetkuo commented Aug 4, 2016

Running all three e2e tests in #29137 gives me

   Expected error:
      <*runtime.notRegisteredErr | 0xc82046c680>: {
          gvk: {Group: "batch", Version: "v1", Kind: "ScheduledJob"},
          t: nil,
      }
      no kind "ScheduledJob" is registered for version "batch/v1"
  not to have occurred

@soltysh
Copy link
Contributor Author

soltysh commented Aug 4, 2016

I haven't got a chance to verify this properly at the time of writing. I'll
revisit this while looking at the remaining PRs we have for SJ.

On Aug 4, 2016 8:02 PM, "Janet Kuo" notifications@github.com wrote:

Running all three e2e tests in #29137
#29137 gives me

Expected error:
<*runtime.notRegisteredErr | 0xc82046c680>: {
gvk: {Group: "batch", Version: "v1", Kind: "ScheduledJob"},
t: nil,
}
no kind "ScheduledJob" is registered for version "batch/v1"
not to have occurred


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#26027 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjLVWylqkGMpxFZUnQtt3k9USTG82Ucks5qcik6gaJpZM4Ij2-x
.

@soltysh soltysh assigned janetkuo and unassigned smarterclayton Aug 8, 2016
@soltysh
Copy link
Contributor Author

soltysh commented Aug 8, 2016

This relies on #30227, I've added option to set the testing group, so no more no kind "ScheduledJob" is registered for version "batch/v1" error 😉
The only problem I have right now is the actual tests, but I'll be working on that and the fact that this group is disabled by default, should I just force enabling everything for e2e, @janetkuo you know by any chance?

@k8s-github-robot k8s-github-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/new-api size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Aug 8, 2016
@janetkuo
Copy link
Member

janetkuo commented Aug 9, 2016

Yes we can enable batch/v2alpha1 in e2e test, but do we also want to test all e2e tests work fine without enabling batch/v2alpha1? @lavalamp may know?

)

var _ = framework.KubeDescribe("ScheduledJob", func() {
options := framework.FrameworkOptions{
Copy link
Member

Choose a reason for hiding this comment

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

Or can we do something like:

f := framework.NewDefaultFramework("scheduledjob")
f.GroupVersion = &unversioned.GroupVersion{Group: batch.GroupName, Version: "v2alpha1"}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd propose leave this as is for now, the end goal is to entirely get rid of the unversioned client, then the problem should disappear and SJ is first on my list, but that will be not sooner than 1.5.

@janetkuo
Copy link
Member

I found a bug in sj controller and you'll need this PR #30327

@k8s-github-robot k8s-github-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 10, 2016
@soltysh
Copy link
Contributor Author

soltysh commented Aug 10, 2016

@kubernetes/sig-testing how can I globally enable batch/v2alpha1 for e2e tests?

@soltysh
Copy link
Contributor Author

soltysh commented Aug 11, 2016

Do we need to test that no jobs are running after sj is deleted? (Do we have the reaper already?)

No reaper yet, need to write one. Will work on it tomorrow.

List jobs (in addition to check sj status) when verifying we have correct number of jobs

Done.

Test ReplaceConcurrent (if this takes too much time, can be a follow-up PR)

Done, but I aslo found a bug there, see #30442

I'll rebase this once your PR lands.

@soltysh soltysh added this to the v1.4 milestone Aug 11, 2016
@janetkuo
Copy link
Member

Reading #30442 makes me think that we should verify pods created by jobs as well.


Reviewed 1 of 1 files at r5.
Review status: all files reviewed at latest revision, 5 unresolved discussions.


test/e2e/scheduledjob.go, line 60 [r5] (raw file):

      jobs, err := f.Client.Batch().Jobs(f.Namespace.Name).List(api.ListOptions{})
      Expect(err).NotTo(HaveOccurred())
      Expect(jobs.Items).To(HaveLen(2))

Could there be more than two jobs?


test/e2e/scheduledjob.go, line 233 [r5] (raw file):

// Wait for a new job to appear.
func waitForNewJob(c *client.Client, ns, previousJobName string) error {

Optional: waitForNewJob may be misused by putting expected job name as the last parameter. How about waitForJobReplaced?


test/e2e/scheduledjob.go, line 240 [r5] (raw file):

      }
      if len(jobs.Items) != 1 {
          return false, nil

If there are more than 1 jobs, should we return error?


Comments from Reviewable

@soltysh
Copy link
Contributor Author

soltysh commented Aug 12, 2016

Review status: all files reviewed at latest revision, 5 unresolved discussions.


test/e2e/scheduledjob.go, line 60 [r5] (raw file):

Previously, janetkuo (Janet Kuo) wrote…

Could there be more than two jobs?

Yeah, it can, I'll change this check to be >= 2

test/e2e/scheduledjob.go, line 233 [r5] (raw file):

Previously, janetkuo (Janet Kuo) wrote…

Optional: waitForNewJob may be misused by putting expected job name as the last parameter. How about waitForJobReplaced?

Done

test/e2e/scheduledjob.go, line 240 [r5] (raw file):

Previously, janetkuo (Janet Kuo) wrote…

If there are more than 1 jobs, should we return error?

Done

Comments from Reviewable

@soltysh
Copy link
Contributor Author

soltysh commented Aug 12, 2016

Reading #30442 makes me think that we should verify pods created by jobs as well.

If you don't mind I'll leave it as a follow up because of that particular issue.

@k8s-bot
Copy link

k8s-bot commented Aug 12, 2016

GCE e2e build/test passed for commit 783df12.

@janetkuo
Copy link
Member

:lgtm:


Reviewed 1 of 1 files at r6.
Review status: all files reviewed at latest revision, 1 unresolved discussion.


Comments from Reviewable

@janetkuo janetkuo added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 12, 2016
@k8s-github-robot
Copy link

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

@soltysh
Copy link
Contributor Author

soltysh commented Aug 12, 2016

I'm removing lgtm label, because this needs #30327 first

@soltysh soltysh removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 12, 2016
@k8s-bot
Copy link

k8s-bot commented Aug 12, 2016

GCE e2e build/test passed for commit 783df12.

@k8s-github-robot
Copy link

Automatic merge from submit-queue

@k8s-github-robot k8s-github-robot merged commit ac1f8bc into kubernetes:master Aug 12, 2016
@soltysh soltysh added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 12, 2016
@soltysh
Copy link
Contributor Author

soltysh commented Aug 12, 2016

Apparently it was too late.

@girishkalele
Copy link

@soltysh The submit queue is blocked since 13:40 due to GKE failures in the ScheduledJob e2e test.
Is the other commit #30327 going to go in soon ?
Otherwise, we should revert this commit till the other goes in ?

@janetkuo
Copy link
Member

Failure on GKE:

[k8s.io] ScheduledJob
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/framework/framework.go:714
  should not schedule new jobs when ForbidConcurrent [It]
  /go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/test/e2e/scheduledjob.go:118

  Expected error:
      <*errors.StatusError | 0xc820bfc300>: {
          ErrStatus: {
              TypeMeta: {Kind: "Status", APIVersion: "v1"},
              ListMeta: {SelfLink: "", ResourceVersion: ""},
              Status: "Failure",
              Message: "the server could not find the requested resource",
              Reason: "NotFound",
              Details: {Name: "", Group: "", Kind: "", Causes: nil, RetryAfterSeconds: 0},
              Code: 404,
          },
      }
      the server could not find the requested resource
  not to have occurred

@janetkuo
Copy link
Member

Does KUBE_RUNTIME_CONFIG work on GKE cluster? (Trying to figure out why it failed on GKE)

@janetkuo
Copy link
Member

Maybe set RUNTIME_CONFIG instead?

@soltysh
Copy link
Contributor Author

soltysh commented Aug 13, 2016

Maybe set RUNTIME_CONFIG instead?

The pattern I've noticed is that I set KUBE_RUNTIME_CONFIG and the script uses that to set RUNTIME_CONFIG because it might want to add something more to that env. I'll look into GKE scripts and update those accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

9 participants