-
Notifications
You must be signed in to change notification settings - Fork 49
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
RHOAIENG-4528 - Customizable kfp-launcher with a config map #630
Conversation
A new image has been built to help with testing out this PR: To use this image run the following: cd $(mktemp -d)
git clone git@github.com:opendatahub-io/data-science-pipelines-operator.git
cd data-science-pipelines-operator/
git fetch origin pull/630/head
git checkout -b pullrequest 3c04640cefd84fc0e47a6a024783670e2b59881f
oc new-project opendatahub
make deploy IMG="quay.io/opendatahub/data-science-pipelines-operator:pr-630" More instructions here on how to deploy and test a Data Science Pipelines Application. |
Change to PR detected. A new PR build was completed. |
Change to PR detected. A new PR build was completed. |
Change to PR detected. A new PR build was completed. |
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.
/lgtm
config/internal/apiserver/default/kfp_launcher_config.yaml.tmpl
Outdated
Show resolved
Hide resolved
/hold |
Change to PR detected. A new PR build was completed. |
Change to PR detected. A new PR build was completed. |
Change to PR detected. A new PR build was completed. |
Change to PR detected. A new PR build was completed. |
Change to PR detected. A new PR build was completed. |
Change to PR detected. A new PR build was completed. |
Change to PR detected. A new PR build was completed. |
Signed-off-by: Achyut Madhusudan <amadhusu@redhat.com>
Change to PR detected. A new PR build was completed. |
Tested as per instructions, both the scenarios are working as expected. But the Persistence Agent pod keeps crashing, also not able to create pipeline runs. Attaching the log file. |
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.
overall approach is correct!
@@ -1,5 +1,9 @@ | |||
apiVersion: v1 | |||
data: | |||
{{ if .APIServer.CustomKfpLauncherConfig }} | |||
providers: | |
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.
(Context: "pipeline root" is a terrible name, and what it actually means is "the base folder in my object storage where all my stuff will go.")
Hm, looks like the user can only set the fields under providers
-- i.e., they can't change defaultPipelineRoot
. That seems incorrect to me.
-
If I'm allowed to override this ConfigMap with my own for the purposes of making the object storage connection exactly what I want, I should absolutely be able to have my pipeline root (base object storage path) set right along side in that same override ConfigMap.
-
Given the (original -- I suggested a change) desription of the field above, as a user, I would be caught off guard if only a subset of the ConfigMap was replaced. I'm expecting to be able to control everything under data.
// CustomKfpLauncherConfig is a custom config file that you can provide | ||
// for the api server to use instead of the one provided with DSPO. |
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.
// CustomKfpLauncherConfig is a custom config file that you can provide | |
// for the api server to use instead of the one provided with DSPO. | |
// Allows the user to fully replace the contents of the kfp-launcher ConfigMap. | |
// kfp-launcher requires a ConfigMap to exist in the namespace where it runs. | |
// This ConfigMap contains pipeline root and object storage configuration. | |
// This ConfigMap must be named "kfp-launcher". We currently deploy a default copy | |
// of the kfp-launcher ConfigMap via DSPO, but a user may want to provide their own | |
// ConfigMap configuration, so that they can specify multiple object storage sources | |
// and paths. The "data" contents of the "kfp-launcher" ConfigMap will be fully replaced | |
// with the "data" contents of the ConfigMap specified here. | |
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.
sorry about the spaces. use tabs :)
// If the custom kfp-launcher configmap is not available, that is OK | ||
if !apierrs.IsNotFound(err) { | ||
log.Error(err, fmt.Sprintf("Encountered error when attempting to fetch ConfigMap: [%s], Error: %v", cfg, err)) | ||
return err |
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.
if it's ok, I think we try to proceed with the defaults as a fallback, just like if the user didn't specify any ConfigMap file at all.
So, don't return an error here -- log it and then keep going. If you return, all the rest of the param setting below doesn't happen.
I'd log something like "User specified a CustomKfpLauncherConfig, but it's not found. Falling back to using defaults."
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.
Yeah my suggestion was to throw the error, but I'm fine with the fallback approach as long as we are providing sufficient logs for users to be able to deduce why their configmap was not picked up.
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.
gotcha. Yeah I like falling back here :) Thanks!
Also, this requires a test to ensure the generated kfp-launcher configmap contains the contents we expect when we override the default one |
moving to #681 /close |
/close |
@gregsheremeta: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/close |
@gregsheremeta: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
The issue resolved by this Pull Request:
Resolves RHOAIENG-4528
Description of your changes:
kfp-launcher is a KFP component that is responsible for fulfilling the "Executor wrapper" and "Publisher" roles as described in the KFP v2 System Design document:
kfp-launcher requires a configmap to exist in the namespace where it runs. This configmap contains pipeline root and object storage configuration. This configmap must be named "kfp-launcher".
We currently deploy a default copy of the kfp-launcher configmap via DSPO, but we want the user to be able to provide their own configmap configuration as well, so that they can specify multiple object storage sources and paths (as described in https://issues.redhat.com/browse/RHOAIENG-4528). This PR adds this functionality.
We don't want to assume anything about the structure of the kfp-launcher configmap (and we know that it will likely change in the future), so this implementation simply copies the data contents of the user-provided configmap into the kfp-launcher configmap.
Testing instructions
kfp-launcher
ConfigMap is the same as the config map we applied earlier.config/samples/v2/dspa-simple/
DSPA in another namespacekfp-launcher
ConfigMap is created with autogenerated values as was always the case.Attachments:
config_map.yaml
dspa.yaml
Checklist