-
Notifications
You must be signed in to change notification settings - Fork 786
Push images to GHCR for release-1.9 #2491
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
Push images to GHCR for release-1.9 #2491
Conversation
/ok-to-test |
Please also sign your commits according to the DCO
And please make sure that you sign with the email that is in the signing key that you have uploaded to github. |
Should this PR not be against the master branch @andreyvelich and then cherry picked to the release branch? |
You are right. We removed only the Training Operator code from the @saileshd1402 Please update the images for Kubeflow Trainer in the master branch, but for Training Operator images you need to create separate PR to update |
Pull Request Test Coverage Report for Build 13823612117Details
💛 - Coveralls |
That's what this PR is for correct? I thought this PR would be for 1.9 only. Should I do the same in master as well? |
38bf74c
to
ec3b1aa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this @saileshd1402!
id: publish | ||
uses: ./.github/workflows/template-publish-image | ||
with: | ||
image: ghcr.io/kubeflow/${{ inputs.component-name }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, we discussed it here, can we keep /trainer/
prefix in the image name: #2455 (comment)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for v1.9, isn't it a good idea to keep training-operator
as prefix instead of trainer
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, great point!
Yes, let's use ghcr.io/kubeflow/training-operator/...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From documentation, looks like ghcr only allows to push to the same repository name (i.e ghcr.io/kubeflow/trainer
). But I think there is no way to test publish to ghcr with training-operator
or trainer
until merge. Should I keep it as trainer
itself?
@@ -48,7 +48,18 @@ jobs: | |||
username: ${{ secrets.DOCKERHUB_USERNAME }} | |||
password: ${{ secrets.DOCKERHUB_TOKEN }} | |||
|
|||
- name: Publish Component ${{ inputs.component-name }} | |||
- name: GHCR Login |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you also update the image in the manifests: https://github.com/kubeflow/trainer/blob/release-1.9/manifests/overlays/standalone/kustomization.yaml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we update this in separate PR? I don't think I'm able to push the images from CI without it being merged first
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we publish images only when PR is merged ?
I thought on pull-request we only verify build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or you mean integration tests are failing due to invalid images in the manifests ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, we publish only on merge, that's why I can't tell exact image tag that will be published, so what should I put in manifest?
- component-name: training-operator-v2 | ||
dockerfile: cmd/training-operator.v2alpha1/Dockerfile | ||
platforms: linux/amd64,linux/arm64,linux/ppc64le | ||
tag-prefix: v2alpha1 | ||
- component-name: model-initializer-v2 | ||
dockerfile: cmd/initializer_v2/model/Dockerfile | ||
platforms: linux/amd64,linux/arm64 | ||
tag-prefix: v2 | ||
- component-name: dataset-initializer-v2 | ||
dockerfile: cmd/initializer_v2/dataset/Dockerfile | ||
platforms: linux/amd64,linux/arm64 | ||
tag-prefix: v2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be missing something. Why do we remove these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought the idea was to not include v2 images in the 1.9 branch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But, we are publishing v2 manager as part of KF release as we can see: https://github.com/kubeflow/manifests/tree/master/apps/training-operator/upstream/v2
@andreyvelich Do you want to remove v2 manifests from KF v1.9 release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think since there are not stable, I prefer to remove them.
We don't have e2e tests or working example in the release branch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM
@juliusvonkohout we are considering of removal https://github.com/kubeflow/manifests/tree/master/apps/training-operator/upstream/v2 from KF 1.9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
V2 is not yet installed by default in Kubeflow Platform 1.9.1 or 1.10.0, we are still on V1. So there is no harm in having them there. Especially once I add integration tests for v2 before enabling v2 by default, we need the v2 manifests there anyway.
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
873597d
to
884bfcd
Compare
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
id: publish-ghcr | ||
uses: ./.github/workflows/template-publish-image | ||
with: | ||
image: ghcr.io/kubeflow/trainer/${{ inputs.component-name }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't use the training-operator prefix since we renamed the repo, right ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about this image, can we re-use it ?
https://github.com/orgs/kubeflow/packages/container/package/training%2Ftraining-operator
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't use the training-operator prefix since we renamed the repo, right ?
yes, from what I understand. but we can't check unless PR is merged I think
What about this image, can we re-use it ?
I can make the changes, but i'm not sure how to test if it will work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can try to merge it, and see if the post-merge job succeed.
We ignore the pushing action in the PR.
Let's try to existing repo and see if that works:
ghcr.io/kubeflow/training/training-operator:<SHA>
ghcr.io/kubeflow/training/storage-initializer:<SHA>
Let's also use the v1.9 as a tag prefix, since it would be more easier to understand for users what is the version of Training Operator it is.
@kubeflow/wg-training-leads @thesuperzapper @juliusvonkohout Any objections ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ghcr.io/kubeflow/training/training-operator:v1.9.1
ghcr.io/kubeflow/training/storage-initializer:v1.9.1
or
ghcr.io/kubeflow/training/training-operator:SHA
ghcr.io/kubeflow/training/storage-initializer:SHA
makes sense, but i am not sure how you want to mix them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And yes speed is more important if i am supposed to release RC.3 tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies for the delay. I have updated the prefix as suggested PTAL
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
username: ${{ github.actor }} | ||
password: ${{ secrets.GITHUB_TOKEN }} | ||
|
||
- name: Publish Component ${{ inputs.component-name }} to Dockerhub |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we consolidate these 2 actions to one similar to this PR: #2537 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for mentioning, I've updated
Signed-off-by: sailesh duddupudi <saileshradar@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you
/approve
I will leave final approval on @andreyvelich
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @saileshd1402!
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andreyvelich, tenzen-y The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in
Fixes #<issue number>, #<issue number>, ...
format, will close the issue(s) when PR gets merged):Fixes #
Checklist: