Feature Area
/area sdk
What feature would you like to see?
Add the same namespace resolution used by other kfp.Client methods to upload_pipeline, list_pipelines, and list_recurring_runs:
namespace = namespace or self.get_user_namespace()
at the start of each method body, before calling the underlying API.
Today, several client methods already resolve namespace this way (for example create_experiment, list_experiments, get_experiment, and list_runs). The three methods above accept an optional namespace argument but pass it through unchanged when callers omit it, even when the client was configured with a user namespace via Client(namespace=...) or the active kubeconfig context.
After the change, callers can omit namespace and still operate in their configured user namespace, consistent with the rest of the client API.
Affected code: sdk/python/kfp/client/client.py — methods upload_pipeline, list_pipelines, and list_recurring_runs.
What is the use case or pain point?
On multi-user Kubeflow deployments, users typically set their namespace once (kubeconfig context or kfp.Client(namespace="kubeflow-user-example-com")). Tools and integrations (Kale, CI scripts, notebooks) then call client methods without repeating the namespace on every call.
When namespace is omitted:
- upload_pipeline may upload to the wrong scope or fail because
namespace=None is sent to the API.
list_pipelines and list_recurring_runs may list resources across all namespaces or behave differently from list_runs / list_experiments, which already honor the configured namespace.
This inconsistency forces every caller to thread namespace through manually and is easy to get wrong in automation that only configures the client once.
Is there a workaround currently?
Yes:
- Pass
namespace explicitly on every call, e.g. client.upload_pipeline(..., namespace=client.get_user_namespace()).
- Or always pass the same string you used when constructing
Client(namespace=...).
Both work but duplicate logic that other client methods already encapsulate and are easy to forget when adding new code paths.
Love this idea? Give it a 👍.
Feature Area
/area sdk
What feature would you like to see?
Add the same namespace resolution used by other
kfp.Clientmethods toupload_pipeline,list_pipelines, andlist_recurring_runs:at the start of each method body, before calling the underlying API.
Today, several client methods already resolve namespace this way (for example
create_experiment,list_experiments,get_experiment, andlist_runs). The three methods above accept an optional namespace argument but pass it through unchanged when callers omit it, even when the client was configured with a user namespace viaClient(namespace=...)or the active kubeconfig context.After the change, callers can omit namespace and still operate in their configured user namespace, consistent with the rest of the client API.
Affected code: sdk/python/kfp/client/client.py — methods
upload_pipeline,list_pipelines, andlist_recurring_runs.What is the use case or pain point?
On multi-user Kubeflow deployments, users typically set their namespace once (kubeconfig context or
kfp.Client(namespace="kubeflow-user-example-com")). Tools and integrations (Kale, CI scripts, notebooks) then call client methods without repeating the namespace on every call.When
namespaceis omitted:namespace=Noneis sent to the API.list_pipelinesandlist_recurring_runsmay list resources across all namespaces or behave differently fromlist_runs/list_experiments, which already honor the configured namespace.This inconsistency forces every caller to thread
namespacethrough manually and is easy to get wrong in automation that only configures the client once.Is there a workaround currently?
Yes:
namespaceexplicitly on every call, e.g.client.upload_pipeline(..., namespace=client.get_user_namespace()).Client(namespace=...).Both work but duplicate logic that other client methods already encapsulate and are easy to forget when adding new code paths.
Love this idea? Give it a 👍.