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
profile-controller: Extend tests for using images of each PR #6820
profile-controller: Extend tests for using images of each PR #6820
Conversation
3d69652
to
cbfcb65
Compare
9ed9950
to
1aea808
Compare
Thanks for the PR @apo-ger! I realized that the
To ensure that we are using the DockerHub registry and that we when the We'll need this because I'd like us to use the |
1aea808
to
248176d
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.
Left some minor comments. Looks good in general!
Signed-off-by: Apostolos Gerakaris <apoger@arrikto.com>
29f36b7
to
8c60846
Compare
@kimwnasptd The tests were failing after #6825 was merged as the applied manifests were looking for the I've updated the PR to use that tag I'd argue that we should also trigger the profile-controller intergration-test workflow when |
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.
Sounds good @apo-ger! Left some more comments towards that direction
- name: Build Kfam Image | ||
run: | | ||
cd components/access-management | ||
make docker-build IMG=${{env.KFAM_IMG}} |
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.
Let's avoid building the kfam
image here. Since in the next iterations #6766 (comment) we'll be using the latest
tag we should be able to use that.
Also currently we use the v1.6.0
tag for kfam, so we don't need to build the image
- name: Load Images into KinD Cluster | ||
run: | | ||
kind load docker-image ${{env.PROFILE_IMG}}:${{env.TAG}} | ||
kind load docker-image ${{env.KFAM_IMG}}:${{env.TAG}} |
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 remove this one as well
export CURRENT_PROFILE_IMG=docker.io/kubeflownotebookswg/profile-controller:v1.6.0 | ||
export CURRENT_KFAM_IMG=docker.io/kubeflownotebookswg/kfam:v1.6.0 | ||
export PR_PROFILE_IMG=${{env.PROFILE_IMG}}:${{env.TAG}} | ||
export PR_KFAM_IMG=${{env.KFAM_IMG}}:${{env.TAG}} |
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.
Let's only update the profile image. We'll just use the KFAM image currently in the manifests, which will become latest
in the future
|
||
env: | ||
PROFILE_IMG: profile-controller | ||
KFAM_IMG: kfam |
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 can remove this one as well
export PR_PROFILE_IMG=${{env.PROFILE_IMG}}:${{env.TAG}} | ||
export PR_KFAM_IMG=${{env.KFAM_IMG}}:${{env.TAG}} | ||
|
||
kustomize build overlays/kubeflow | sed "s#$CURRENT_PROFILE_IMG#$PR_PROFILE_IMG#g" | sed "s#$CURRENT_KFAM_IMG#$PR_KFAM_IMG#g" | kubectl apply -f - |
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 lastly, same here. Let's just update the profile controller image for now
8c60846
to
f79791b
Compare
And update on my last round of comments, after chatting a little bit with @apo-ger as well. We decided to keep one workflow file for building/testing both KFAM and Profiles. But this is not ideal and we need to create some issues for next steps and expose some context: KFAM is using a stable version of ProfilesRight now KFAM is using the Profiles code from a specific (and very old) commit https://github.com/kubeflow/kubeflow/blob/master/components/access-management/go.mod#L38 This means that there's no way to test now if a change in the Profiles will break KFAM. We need to re-evaluate how to have KFAM uses the code from the Profiles Controller. We need KFAM to always use the latest code of Profiles and not bind it to a specific commit. We had done this for the Notebook Controller https://github.com/kubeflow/kubeflow/blob/v1.5-branch/components/notebook-controller/go.mod#L18-L21 But looking at Notebooks I realized we had a regression on this in v1.6 :-) |
99c72a8
to
f9b985c
Compare
So, the ideal state I have in mind is:
So @apo-ger ignore my above comments for not building KFAM. Let's have one workflow for both and have a follow-up issue on making KFAM to use the local code of Profiles, to ensure we won't end up with broken KFAM from Profiles. |
Signed-off-by: Apostolos Gerakaris <apoger@arrikto.com>
Signed-off-by: Apostolos Gerakaris <apoger@arrikto.com>
* Trigger workflow when kfam code changes since KFAM manifests are deployed with Profile Controller manifests. * Build KFAM image as well and update manifests with sed before deploying them in the KinD cluster. * Update tag in manifests to v1.6.0 since the images with tag v1.5.0 do not exist in Dockerhub. Signed-off-by: Apostolos Gerakaris <apoger@arrikto.com>
f9b985c
to
ac921f3
Compare
@kimwnasptd Thanks for all the comments and the context! I've also updated the PR to publish the kfam image only when a PR is merged as mentioned in #6766 (comment). |
Thank you for the work @apo-ger! /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kimwnasptd 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 |
This PR resolves part of: #6766
Changes: