Release v0.1.0

[danielvegamyhre]

Release Checklist

• [x] All OWNERS must LGTM the release proposal
• [x] Verify that the changelog in this issue is up-to-date
• [x] For major or minor releases (v$MAJ.$MIN.0), create a new release branch.
  • [x] an OWNER creates a vanilla release branch with git branch release-$MAJ.$MIN main
  • [x] An OWNER pushes the new release branch with git push release-$MAJ.$MIN
• [x] Update things like README, deployment templates, docs, configuration, test/e2e flags. Submit a PR against the release branch:
• [x] An OWNER prepares a draft release
  • [x] Write the change log into the draft release.
  • [x] Run make artifacts IMAGE_REGISTRY=registry.k8s.io/jobset GIT_TAG=$VERSION to generate the artifacts and upload the files in the artifacts folder to the draft release.
• [x] An OWNER creates a signed tag running git tag -s $VERSION and inserts the changelog into the tag description. To perform this step, you need a PGP key registered on github.
• [x] An OWNER pushes the tag with git push $VERSION
  • Triggers prow to build and publish a staging container image gcr.io/k8s-staging-jobset/jobset:$VERSION
• [x] Submit a PR against k8s.io, updating k8s.gcr.io/images/k8s-staging-jobset/images.yaml to promote the container images to production:
• [x] Wait for the PR to be merged and verify that the image registry.k8s.io/jobset/jobset:$VERSION is available.
• [x] Publish the draft release prepared at the Github releases page.
• [x] Add a link to the tagged release in this issue:
• [x] Send an announcement email to sig-apps@kubernetes.io, sig-scheduling@kubernetes.io and wg-batch@kubernetes.io with the subject [ANNOUNCE] JobSet $VERSION is released
• [x] Add a link to the release announcement in this issue:
• [x] For a major or minor release, update README.md and docs/setup/install.md in main branch:
• [x] For a major or minor release, create an unannotated devel tag in the main branch, on the first commit that gets merged after the release branch has been created (presumably the README update commit above), and, push the tag: DEVEL=v0.$(($MAJ+1)).0-devel; git tag $DEVEL main && git push $DEVEL This ensures that the devel builds on the main branch will have a meaningful version number.
• [x] Close this issue

Changelog

• Support creating Jobs of different templates or many jobs from the same template
• Enable pod-to-pod communication via pod hostnames
• Support for 1:1 job to topology domain assignment
• Default success policy: JobSet succeeds when all jobs are completed
• Default failure policy: Jobset fails if any job fails
• Support for specifying a failure policy with a maximum number of times a jobset can be restarted before failing
• Support for suspending and resuming a JobSet
• Defaulting and validation webhook
• Webhook uses internal cert by default; user can use cert-manager as second choice

[danielvegamyhre]

/assign

[danielvegamyhre]

@ahg-g I listed the main features in the changelog above, anything you want to add?

[charles-chenzz]

Default using internal cert: user can use cert-manager as second choice do we need to specify this? if not, please ignore this comment

[danielvegamyhre]

thanks @charles-chenzz, I added this to the changelog

[ahg-g]

• Webhook uses internal cert by default; user can use cert-manager as second choice

I made some edits to the first bullet.

Webhook uses internal cert by default; user can use cert-manager as second choice

How can they use cert-manager? if this is possible, please lets add it to the documentation.

[danielvegamyhre]

@ahg-g They would need to install cert-manager on their cluster with kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.yaml then update this line in the config yaml to say ../components/certmanager, then uncomment all the sections beginning with [CERTMANAGER]. Perhaps we shouldn't explicitly support this? Seems kind of hacky to me, I would be in favor of removing cert manager altogether in the future unless there is some benefit to keeping it.

[ahg-g]

I think for security reasons, some organizations will want to use cert-manager since it implements cert rotation

[tenzen-y]

I think for security reasons, some organizations will want to use cert-manager since it implements cert rotation

Agree. In production env, such as running both serving (prediction) and training for ML Apps, we often manage many certs by the cert-manager. In that case, we would prefer to handle all certs (including certs for the webhook) by the cert-manager.

[danielvegamyhre]

I see, that makes sense. I created tracking issue #105 for the relevant documentation updates.

[danielvegamyhre]

Successfully pulled registry.k8s.io/jobset/jobset:v0.1.0 with docker.

[tenzen-y]

Successfully pulled registry.k8s.io/jobset/jobset:v0.1.0 with docker.

I confirmed that the image can be pulled.

$ docker pull registry.k8s.io/jobset/jobset:v0.1.0
v0.1.0: Pulling from jobset/jobset
a7ca0d9ba68f: Pull complete 
fe5ca62666f0: Pull complete 
b02a7525f878: Pull complete 
fcb6f6d2c998: Pull complete 
e8c73c638ae9: Pull complete 
1e3d9b7d1452: Pull complete 
4aa0ea1413d3: Pull complete 
7c881f9ab25e: Pull complete 
5627a970d25e: Pull complete 
03e20a23062b: Pull complete 
Digest: sha256:bab26f4d7f550f0b9afe92192cfb4751e3706a5ca6159f67ca93119b81221954
Status: Downloaded newer image for registry.k8s.io/jobset/jobset:v0.1.0
registry.k8s.io/jobset/jobset:v0.1.0
$ docker image inspect registry.k8s.io/jobset/jobset:v0.1.0 | jq '.[].RepoDigests'
[
  "registry.k8s.io/jobset/jobset@sha256:bab26f4d7f550f0b9afe92192cfb4751e3706a5ca6159f67ca93119b81221954"
]

[ahg-g]

/lgtm

[danielvegamyhre]

Release v0.1.0 published: https://github.com/kubernetes-sigs/jobset/releases/tag/v0.1.0

[danielvegamyhre]

Announcement email link: https://groups.google.com/a/kubernetes.io/g/wg-batch/c/cjZ3ZmiptQ8