You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
👍 We've reviewed this issue and have agreed to add it to our backlog. Please subscribe to this issue for notifications, we'll provide updates when we pick it up.
We also welcome community contributions! If you would like to pick this item up sooner and submit a pull request, please visit our contribution guidelines and assign this to yourself by commenting "/assign" on this issue.
For more information on our triage process please visit our triage overview
It was an intentional choice for rad workspace to not mutate state on the server.
Part of the motivation was that we had a lot of confusion about whether rad workspace was a client-side concept or a server-side concept (it's a purely client-side concept, like a KubeConfig).
I think there's some value digging into the scenario as you encountered it:
What should be the experience when you install Radius from Helm? What's created for you by default and what's not?
/cc @zachcasper - any thoughts about the scenario?
Steps to reproduce
~/.kube/config
install radius via the helm chart as described hererad group create dev
returns an errorrad workspace create kubernetes dev
and ensure the command executes successfully.rad group create dev
andrad env create dev -g dev
, both should now execute successfully.rad create workspace kubernetes dev -g dev -e dev --force
Observed behavior
No response
Desired behavior
The rad cli is aware of the radius deployment and when creating the workspace should
env
andgroup
be created if they do not exist?Workaround
Workaround in steps to reproduce
rad Version
RELEASE VERSION BICEP COMMIT
0.40.0 v0.40.0 0.31.92 91603b3
Operating system
macOS Sequoia m1
Additional context
No response
Would you like to support us?
AB#13796
The text was updated successfully, but these errors were encountered: