update driver & launcher image handling #11533
Conversation
This change relies on manifest yamls to specify the launcher & driver that is pinned to a specific KFP version. The goal is to decouple having to build launcher/driver at separate stages compared to api server. This is accomplished by setting the hardcoded default to point to "latest" and during release, api server is built with this hardcoding, and the images for driver/launcher are patched into manifests post build along with the other images. The apiserver deployment manifest is reformatted using yq so the next time the release.sh is ran, the user is not surprised by the entire file reformatting unexpectedly. Signed-off-by: Humair Khan <[email protected]>
|
cc @chensun |
Signed-off-by: Humair Khan <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| @@ -30,9 +30,9 @@ import ( | |||
| const ( | |||
| volumeNameKFPLauncher = "kfp-launcher" | |||
| volumeNameCABundle = "ca-bundle" | |||
| DefaultLauncherImage = "ghcr.io/kubeflow/kfp-launcher:2.4.0" | |||
| DefaultLauncherImage = "ghcr.io/kubeflow/kfp-launcher:latest" | |||
There was a problem hiding this comment.
Can you please add a comment above mentioning that the latest tag will be replaced by with a pinned version at release time?
There was a problem hiding this comment.
@chensun the goal is to pin the version from the manifests, seen here
Apologies for the large diff on the yaml, the only change is what is highlighted above in the link, the rest is just fixing indenting. The idea is to keep this latest in code (even for releases) and update the version in the manifests so we can build all these images (including api server, etc.) all at once during releases. Let me know what you think about this. Having versions embedded in code, requires us to always build driver/launcher, then commiting code changes first, before initiating the rest of the image builds afterwards.
There was a problem hiding this comment.
If there is concern about having latest in code, in a release version, we can also make the driver/launcher env vars a hard requirement, and throw an error when it is not provided, and simply not have a default hardcoded tag at all
Description of your changes:
This change relies on manifest yamls to specify the launcher & driver that is pinned to a specific KFP version. The goal is to decouple having to build launcher/driver at separate stages relative to api server.
This is accomplished by setting the hardcoded default to point to "latest" and during release, api server is built with this hardcoding, and the images for driver/launcher are patched into manifests post build along with the other images.
The apiserver deployment manifest is reformatted using yq so the next time the release.sh is ran, the user is not surprised by the entire file reformatting unexpectedly.
A PR with update to the release docs will follow.
Checklist: