Workspace refactor feature spec#11775
Conversation
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
There was a problem hiding this comment.
Pull request overview
Adds a CLI feature specification design note proposing to replace the user-facing “workspace” concept with per–kube-context defaults managed via rad configure --defaults, while keeping legacy workspaces: data as read-only compatibility for --workspace.
Changes:
- Introduces a new feature spec describing UX rationale and command surface (
rad configure --defaults,--list-defaults). - Defines config schema changes (
defaults:keyed by kube context) and a per-key precedence/resolution order with legacy fallback. - Documents user stories, edge cases, and functional requirements (including concurrency/atomic-write expectations).
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
| ### Top level goals | ||
|
|
||
| - Eliminate "workspace" as a user-visible concept in Radius CLI help, docs, and error messages for new users. | ||
| - Replace `rad workspace switch` / `rad group switch` / `rad env switch` with a single, discoverable `rad configure --defaults` surface. |
There was a problem hiding this comment.
Are the commands listed here all consistent with their use of --group and --environment flags? If not, lets include modifying them to be consistent.
| - Eliminate "workspace" as a user-visible concept in Radius CLI help, docs, and error messages for new users. | ||
| - Replace `rad workspace switch` / `rad group switch` / `rad env switch` with a single, discoverable `rad configure --defaults` surface. | ||
| - Make per-cluster defaults automatic by keying them on the active Kubernetes context, so `kubectl config use-context` is sufficient to switch Radius targets. | ||
| - Preserve backward compatibility for existing `~/.rad/config.yaml` files and for scripts that pass `--workspace <name>`. |
|
|
||
| ### Non-goals (out of scope) | ||
|
|
||
| - Multiple named "profiles" per kube context. Users wanting multiple environments on the same cluster use `--group`/`--environment` flags or maintain separate kube contexts. |
There was a problem hiding this comment.
Would it be worthwhile to repurpose the yaml config file to remember the defaults per kube config? So that when they configure a default in one kubectl context, the defaults are remembered for the next time they switch back to that context.
Edit: It looks like that is called out in scenario 3.
|
|
||
| ### Scenario 6: JSON-friendly defaults for scripting and CI | ||
|
|
||
| `rad configure --list-defaults --output json` returns a stable, scriptable schema. `rad configure --defaults …` runs non-interactively in CI, exiting non-zero with a stable error code on validation failure. |
There was a problem hiding this comment.
Do we need to enable rad configure to accept the same json format as in input argument?
|
|
||
| > After this is implemented, I can install Radius, run `rad init`, and immediately deploy an application without ever typing or seeing the word "workspace". When I want different defaults, I run one command — `rad configure --defaults group=<name> environment=<name>` — modeled on the `az configure --defaults` pattern I already know. When I switch Kubernetes clusters with `kubectl config use-context`, my Radius defaults follow automatically because they are keyed on the active context. When I need to override defaults for a single command, I pass `-g`, `-e`, or `-w` and the precedence is consistent and predictable. As a result, my mental model is two concepts (resource group, environment) instead of three, my cluster-switching is one command instead of two, and my onboarding doc is shorter. | ||
|
|
||
| ### Detailed user experience |
There was a problem hiding this comment.
Are we saying Radius automatically resolves all the commands to default group and default environment when there are no non-defaults set ?
This eliminates all the switch commands and kube config serves as the operating cluster.
willtsai
left a comment
willtsai
left a comment
There was a problem hiding this comment.
One of the things I find useful with Workspaces is the ability to deploy to a given kubecontext without needing to first point at that context. For example:
- I'm currently in my
local-devkubecontext - I have an
aks-prodkubecontext set up as well, and that is associated with myaks-prodWorkspace - I can issue commands like
rad deploy app.bicep -w aks-prodto target a separate kubecontext while remaining in another kubecontext
I'm wondering if there will be a replacement or workaround for this use case in this proposal, or is the idea that this is not reflective of how someone would actually use Radius?
Description
This is a feature spec for refactoring the rad CLI workspace to be easier to use and understand.
Type of change
Contributor checklist
Please verify that the PR meets the following requirements, where applicable: