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

Added JobTemplate, a preliminary step for ScheduledJob and Workflow #21675

Merged
merged 4 commits into from
May 11, 2016

Conversation

soltysh
Copy link
Contributor

@soltysh soltysh commented Feb 22, 2016

@sdminonne as promised, sorry it took this long 😊
@erictune fyi though it does not have to be in for 1.2


This change is Reviewable

@k8s-github-robot k8s-github-robot added kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Feb 22, 2016
@sdminonne
Copy link
Contributor

@soltysh thanks.

// JobTemplate describes a template for creating copies of a predefined pod.
type JobTemplate struct {
unversioned.TypeMeta `json:",inline"`
v1.ObjectMeta `json:"metadata,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

use the same hyperlinks as PodTemplate comments

@erictune
Copy link
Member

I suggest we wait for after 1.2 to merge this.

@erictune
Copy link
Member

So, this PR seems fine.

I'm guessing the next PR is going to add "ScheduledJob". I am not sure where that goes.
I don't think it can go into batch/v1 since ScheduledJob won't be v1 on the first release.

I think what needs to happen is that we need to create a batch/v2alpha1 which has Job and ScheduledJob in it, and that group needs to advance through batch/v2beta1 and then batch/v2,
at which point ScheduledJob will be GA. During that time, Jobs will be accessible through 3 or more endpoints. It seems a bit complex, but I'm not sure what the alternative is.
@lavalamp @bgrant0607 @deads2k

By the way, it makes it kind of an incentive to get Workflow in at the same time as ScheduledJob, to avoid a v3alpha1.

@soltysh
Copy link
Contributor Author

soltysh commented Feb 25, 2016

I suggest we wait for after 1.2 to merge this.

Yes, that was the point.

I think what needs to happen is that we need to create a batch/v2alpha1 which has Job and ScheduledJob in it

Why can't we just use Job from batch/v1 I'd personally stay away from creating Jobs in it.

Other silly question, instead of messing batch sub-group, can't we use extensions/v1beta1 or extensions/v2beta1 as the incubator for new types, since the internal is already in place. And then move to appropriate group only when GA?

@soltysh
Copy link
Contributor Author

soltysh commented Feb 25, 2016

@erictune added the urls you've asked for.

@sdminonne
Copy link
Contributor

@erictune @soltysh, I plan to submit a PR for workflow and for the moment it will be in pkg/apis/extensions/v1beta1 but I'm OK to modify according to other needs/policy

@erictune
Copy link
Member

@bgrant0607 @lavalamp we need to decide what to do in this case:

  • we are introducing an alpha-version of a new Kind (e.g. ScheduledJob or Workflow)
  • we know already what the API group for the new kind it will eventually be (e.g. Batch)
  • there is already something in the eventual destination group (e.g. Job is already in Batch/v1).

Considerations:

  • extensions/v1beta1 is where we have been putting stuff, so it is easy/consistent to put new things there
  • but... extensions/v1beta1 was a hack for when we didn't have api groups working in general. we should stop using it now?
  • the internal for Job is in extensions/v1beta1, and so putting things that use it in extensions/v1beta1 is convenient
  • but... we have a plan to remove Job from there in version 1.4, and we would not be able to migrate ScheduledJob or Workflow out of extensions on the same schedule
  • assuming ScheduledJob or Workflow went into extensions first, and then was ready for GA, where does it go for GA? Batch/v1 or Batch/v2? The former makes sense because there is not any change to Job planned, so no need to rev the group for that. And it is less work. The latter makes sense since we once said that we would not add new things to an API group once it had been formed, so that users could use the presence of the api group to determine the presence of all enclosing kinds.

@bgrant0607
Copy link
Member

@erictune If there's nothing here that needs to be decided for 1.2, I'll have to look at this later.

@erictune
Copy link
Member

no 1.2 issues.

@lavalamp
Copy link
Member

Ping me again after 1.2 and I'll have lots to say. :)

On Thu, Feb 25, 2016 at 9:06 AM, Eric Tune notifications@github.com wrote:

no 1.2 issues.


Reply to this email directly or view it on GitHub
#21675 (comment)
.

@sdminonne
Copy link
Contributor

@soltysh ping :)

@lavalamp
Copy link
Member

I'm paying attention to PRs again. I will come back to this one once I triage my entire queue.

@sdminonne
Copy link
Contributor

Thanks

@soltysh
Copy link
Contributor Author

soltysh commented Mar 18, 2016

@lavalamp yeah, that will be needed for the scheduled jobs I'm hoping to start next week.

type JobTemplateSpec struct {
// Standard object's metadata.
// More info: http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#metadata
v1.ObjectMeta `json:"metadata,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

You should not need this except in top-level objects.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is similar to PodTemplateSpec to allow us define created Job's metadata fields.

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'll update the comment to give my reasoning.

@soltysh
Copy link
Contributor Author

soltysh commented Mar 22, 2016

@lavalamp removed from v1beta1 and updated the comments, ptal

@lavalamp
Copy link
Member

@k8s-bot test this issue: #23365

OK, this LGTM.

@lavalamp lavalamp added lgtm "Looks good to me", indicates that a PR is ready to be merged. and removed lgtm "Looks good to me", indicates that a PR is ready to be merged. labels Mar 23, 2016
@soltysh
Copy link
Contributor Author

soltysh commented May 6, 2016

Sorry, forgot to run hack/update-all.sh.

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

soltysh commented May 9, 2016

Rebased, I didn't forget to run hack/update-all.sh this time, so hopefully should be a green one. I've also updated defaults.go according to recent changes.
@erictune || @lavalamp mind re-adding the lgtm label.

@k8s-github-robot k8s-github-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels May 9, 2016
@soltysh
Copy link
Contributor Author

soltysh commented May 10, 2016

@erictune || @lavalamp mind re-adding the lgtm label, I'd like to avoid rebasing once again.

@k8s-github-robot k8s-github-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 10, 2016
@erictune erictune added lgtm "Looks good to me", indicates that a PR is ready to be merged. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. labels May 10, 2016
@soltysh
Copy link
Contributor Author

soltysh commented May 11, 2016

@k8s-bot test this github issue: #24211

@k8s-github-robot
Copy link

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

@k8s-bot
Copy link

k8s-bot commented May 11, 2016

GCE e2e build/test passed for commit a31ca0d.

@k8s-github-robot
Copy link

Automatic merge from submit-queue

@k8s-github-robot k8s-github-robot merged commit ef885d0 into kubernetes:master May 11, 2016
@soltysh
Copy link
Contributor Author

soltysh commented May 11, 2016

🎉

@soltysh soltysh deleted the job_template branch May 11, 2016 09:44
@erictune
Copy link
Member

👍

k8s-github-robot pushed a commit that referenced this pull request May 12, 2016
Automatic merge from submit-queue

Scheduledjob api

@erictune ScheduledJob api types, based on #21675, so only last two commits counts.
@sdminonne fyi

```release-note
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](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/.github/PULL_REQUEST_TEMPLATE.md?pixel)]()
openshift-publish-robot pushed a commit to openshift/kubernetes that referenced this pull request Jan 29, 2019
UPSTREAM: 71074: fix device path being empty

Origin-commit: f129e1f66f6da7a33f66d8382ab6b3341eccdf48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API lgtm "Looks good to me", indicates that a PR is ready to be merged. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.