feat(cli): add velero client config set namespace-mode=auto

[lubronzhan]

Summary

• Adds namespace-mode=auto as a velero client config set value. When set, Velero operational commands resolve their default namespace from the current kubeconfig context (or --kubecontext/--kubeconfig if specified) on every invocation, instead of a static stored value.
• This lets users who run Velero against a non-default namespace stay in sync automatically as they switch kubeconfig contexts, without re-running a command or passing --namespace on every invocation.

Test plan

• go build ./... succeeds
• go vet / gofmt clean on new/changed files
• go test ./pkg/client/... ./pkg/cmd/cli/client/... passes
• Added factory tests covering: namespace resolved from kubecontext in auto mode, namespace tracking a kubecontext change, --namespace flag overriding auto mode, and VELERO_NAMESPACE overriding auto mode
• Reviewer to confirm this addresses the use case from the issue

AI-Tool-Used: Claude Code
AI-Tool-Use-Level: Category 2 (Medium)
AI-Code-Category: Category 1 (Production)

[netlify]

👷 Deploy request for velero pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	6e76b92

[lubronzhan]

@kaovilai Since you proposed this approach (set-context-as-velero-namespace) on the issue, would appreciate your review here. Thanks!

[codecov]

Codecov Report

❌ Patch coverage is 92.00000% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/client/config.go	75.00%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[kaovilai]

Adds velero client set-context-as-velero-namespace to persist the current kubeconfig context's namespace into the Velero client config — a lower-risk alternative to changing default namespace resolution. has-unit-tests, CI green (61 checks), no outstanding review threads.

Note

Responses generated with Claude

[kaovilai]

Thanks for this easy kill. I think this is a cool PR to slightly improve usability.

[lubronzhan]

Thanks for this easy kill. I think this is a cool PR to slightly improve usability.

Thanks @kaovilai is it ok to merge this PR now?

[kaovilai]

Our repository is set up so that two reviewers are required, so we will need another reviewer. Please wait.

[shubham-pampattiwar]

Thanks for picking this up. The code is clean and well-tested. I have a few concerns about the approach before we merge.

CLI hierarchy: This command sits at velero client set-context-as-velero-namespace, but the existing way to set the namespace is velero client config set namespace=.... Adding a sibling command to client that does a subset of what config already handles breaks the CLI structure. This should live under velero client config if we add it.

Command naming: set-context-as-velero-namespace is hard to parse. It reads like "set the context as the velero namespace" when it actually means "read the namespace from my kubeconfig context and save it as velero's default." Something like velero client config set-from-context would be shorter and clearer.

Does this close #3194?: The original issue asks for the Velero CLI to automatically use the active namespace from the current kubeconfig context. This PR still requires the user to manually run a command every time they switch contexts. It's a convenience wrapper around the existing velero client config set namespace=... -- useful, but it doesn't address the core ask. I don't think we should close #3194 with this.

Value vs surface area: Today a user can achieve this with:

velero client config set namespace=$(kubectl config view --minify -o 'jsonpath={..namespace}')

Adding a dedicated command for this means more CLI surface to maintain and document. The tradeoff might be worth it if we get the placement and naming right, but as-is I'd want to see the command restructured before merging.

[lubronzhan]

Does this close #3194?: The original issue asks for the Velero CLI to automatically use the active namespace from the current kubeconfig context. This PR still requires the user to manually run a command every time they switch contexts. It's a convenience wrapper around the existing velero client config set namespace=... -- useful, but it doesn't address the core ask. I don't think we should close #3194 with this.

That's correct, the original ask propose a breaking change on the default behavior not sure we really wants that that's why I pick this approach.

Let me update the description.

[lubronzhan]

Hi @shubham-pampattiwar Please take a look see if you are ok with the new change. Thank you

[kaovilai]

on original ask.. yeah do you think original ask is a more valid usecase? I thought its more convenient for velero to remember ns.. but if you are the type that bounce between two velero instances.. perhaps velero should defer to current ns as original issue ask. In that case, perhaps the config should allow for another option, auto namespace mode?

[lubronzhan]

on original ask.. yeah do you think original ask is a more valid usecase? I thought its more convenient for velero to remember ns.. but if you are the type that bounce between two velero instances.. perhaps velero should defer to current ns as original issue ask. In that case, perhaps the config should allow for another option, auto namespace mode?

@kaovilai MM make sense. And current command could be easily replaced by config set --namespace ? Not a big difference.

So maybe a command to allow use to enable this auto context switch? Like velero client config set namespace-mode=auto

Then do you think velero client config set-namespace-from-context is still useful? If not I can remove it

[kaovilai]

if we have velero client config set namespace-mode=auto then velero client config set-namespace-from-context is no longer useful.. and if it was, its probably not much harder than currently available alternative.

[lubronzhan]

Good point @kaovilai, thanks. Replaced the one-shot set-namespace-from-context command with a velero client config set namespace-mode=auto toggle instead — when set, the client factory resolves the namespace from the current kubeconfig context dynamically on every command, so it stays in sync as you switch contexts without needing a dedicated command (or having to rerun it). `--namespace` and `VELERO_NAMESPACE` still take precedence when set explicitly.

[kaovilai]

Document how to disable auto mode. Since the generic setter deletes a key using an empty value, users apparently need velero client config set namespace-mode=. Adding that command to namespace.md would make the feature reversible and discoverable.

Add fallback/error-path coverage. Namespace() silently falls back to the stored/default namespace when kubeconfig namespace resolution fails. Even if this behavior is intentional because the interface cannot return an error, a test should lock it down and the docs should mention the fallback.

Use t.Setenv in new tests. This provides automatic cleanup and avoids environment leakage if a test exits early.

[lubronzhan]

Document how to disable auto mode. Since the generic setter deletes a key using an empty value, users apparently need velero client config set namespace-mode=. Adding that command to namespace.md would make the feature reversible and discoverable.

Add fallback/error-path coverage. Namespace() silently falls back to the stored/default namespace when kubeconfig namespace resolution fails. Even if this behavior is intentional because the interface cannot return an error, a test should lock it down and the docs should mention the fallback.

Use t.Setenv in new tests. This provides automatic cleanup and avoids environment leakage if a test exits early.

Cool, done

[kaovilai]

Thanks for this work!