Adding auth made the target the thing a person selects. The rest of the CLI has not caught up: it still asks people to think in kube contexts and kubeconfig files, and in one case refuses a command because of it.
What is wrong today
Everyday commands select a cluster the old way. --context names a kube context, not a target. So this fails even though the cluster named is a configured target:
$ burrow addon list --context do-nyc1-burrow-cloud
burrow: --context picks a cluster out of your kubeconfig, and the active target "burrow-cloud.dev"
is the managed product at burrow-cloud.dev, which has no cluster of its own. Drop the flag, or
switch to a cluster target with "burrow auth switch <name>"
Both are in the list:
ACTIVE TARGET KIND DETAIL
* burrow-cloud.dev burrow-cloud the managed product at burrow-cloud.dev
do-nyc1-burrow-cloud kubernetes kube context "do-nyc1-burrow-cloud"
cmd/burrow/main.go:563 (cloudTarget) refuses any kubeconfig-shaped flag when the active target is a cloud one, and it is right to: the flag belongs to a vocabulary these commands should no longer be using. The two options it offers are both bad — "drop the flag" runs somewhere else, and "switch" changes global state for every shell to run one read-only command.
A human target is not scoped. localconfig.Target records Context: the name of a context in the person's ambient kubeconfig, carrying whatever privileges that context has — usually cluster-admin.
And the fix for that already exists, for the agent only. The same struct carries AgentKubeconfig and AgentContext, written by SetAgentCredential, because ADR-0038 mints a scoped least-privilege kubeconfig for the agent at ~/.burrow/agents/ and points the target at it. A person gets no equivalent.
What it should be
1. --target, not --context
Everyday commands select by target name — the names burrow auth status prints — and one flag covers both kinds, because a target is a target whether it is a cluster or the managed product:
burrow addon list --target do-nyc1-burrow-cloud
It selects for one invocation and leaves the active target alone, which is the whole point: running one command elsewhere should not require changing global state and remembering to change it back.
A --target naming something that is not in the list is a refusal, and the current message is the right shape for it — it just needs to talk about targets.
--context and --kubeconfig belong to auth login, where a person is deliberately choosing which cluster to connect. Everywhere else they should go, on the usual deprecation path rather than by removal.
2. auth login mints a scoped context, the way agent install already does
Connecting a cluster should create a credential scoped to what Burrow needs and record it on the target, instead of recording the name of an ambient admin context and using that for every later command.
The mechanism is built and shipped — ADR-0038 for the agent, and ADR-0084's per-person credentials (internal/clustercred, burrow auth login) for identity. What is missing is the same treatment for a human's cluster access. That likely wants its own record, since it decides what the scope is and what happens to targets configured before it.
3. The vocabulary follows
Once selection is by target, user-facing text outside auth should stop mentioning kubeconfigs. It is currently everywhere: cmd/burrow/env.go has 53 mentions, main.go 38, install.go 37, with flag help like "path to kubeconfig used to resolve the followed context" repeated verbatim in several places. What a person sees today:
--discover probes the clusters in your kubeconfig for an installed Burrow, and the active target ...
(missing) that kube context is not in your kubeconfig, so the handle points at nothing.
context %q is not in your kubeconfig; available: %s
Someone running burrow addon list is asking about their add-ons, not about a file on their disk.
Scope: user-facing strings — command help, flag descriptions, errors. Not comments, not identifiers, not tests except where they assert on changed text. auth keeps kubeconfig vocabulary, because that is where connecting a cluster genuinely happens.
Sweep for the phrase at the end. A half-renamed vocabulary is worse than either one consistently, because a reader seeing both assumes they are two different things.
Order
1 is small and unblocks the immediate annoyance. 3 is mechanical once 1 lands and gives the sweep something to be consistent with. 2 is the real design work and should not be rushed to keep the other two company.
Adding
authmade the target the thing a person selects. The rest of the CLI has not caught up: it still asks people to think in kube contexts and kubeconfig files, and in one case refuses a command because of it.What is wrong today
Everyday commands select a cluster the old way.
--contextnames a kube context, not a target. So this fails even though the cluster named is a configured target:Both are in the list:
cmd/burrow/main.go:563(cloudTarget) refuses any kubeconfig-shaped flag when the active target is a cloud one, and it is right to: the flag belongs to a vocabulary these commands should no longer be using. The two options it offers are both bad — "drop the flag" runs somewhere else, and "switch" changes global state for every shell to run one read-only command.A human target is not scoped.
localconfig.TargetrecordsContext: the name of a context in the person's ambient kubeconfig, carrying whatever privileges that context has — usually cluster-admin.And the fix for that already exists, for the agent only. The same struct carries
AgentKubeconfigandAgentContext, written bySetAgentCredential, because ADR-0038 mints a scoped least-privilege kubeconfig for the agent at~/.burrow/agents/and points the target at it. A person gets no equivalent.What it should be
1.
--target, not--contextEveryday commands select by target name — the names
burrow auth statusprints — and one flag covers both kinds, because a target is a target whether it is a cluster or the managed product:It selects for one invocation and leaves the active target alone, which is the whole point: running one command elsewhere should not require changing global state and remembering to change it back.
A
--targetnaming something that is not in the list is a refusal, and the current message is the right shape for it — it just needs to talk about targets.--contextand--kubeconfigbelong toauth login, where a person is deliberately choosing which cluster to connect. Everywhere else they should go, on the usual deprecation path rather than by removal.2.
auth loginmints a scoped context, the wayagent installalready doesConnecting a cluster should create a credential scoped to what Burrow needs and record it on the target, instead of recording the name of an ambient admin context and using that for every later command.
The mechanism is built and shipped — ADR-0038 for the agent, and ADR-0084's per-person credentials (
internal/clustercred,burrow auth login) for identity. What is missing is the same treatment for a human's cluster access. That likely wants its own record, since it decides what the scope is and what happens to targets configured before it.3. The vocabulary follows
Once selection is by target, user-facing text outside
authshould stop mentioning kubeconfigs. It is currently everywhere:cmd/burrow/env.gohas 53 mentions,main.go38,install.go37, with flag help like "path to kubeconfig used to resolve the followed context" repeated verbatim in several places. What a person sees today:Someone running
burrow addon listis asking about their add-ons, not about a file on their disk.Scope: user-facing strings — command help, flag descriptions, errors. Not comments, not identifiers, not tests except where they assert on changed text.
authkeeps kubeconfig vocabulary, because that is where connecting a cluster genuinely happens.Sweep for the phrase at the end. A half-renamed vocabulary is worse than either one consistently, because a reader seeing both assumes they are two different things.
Order
1 is small and unblocks the immediate annoyance. 3 is mechanical once 1 lands and gives the sweep something to be consistent with. 2 is the real design work and should not be rushed to keep the other two company.