Skip to content

feat: Unhide workspace rename command #5464

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 19, 2022

Conversation

mafredri
Copy link
Member

@mafredri mafredri commented Dec 19, 2022

I think we've made a best-effort to protect user volumes so that we can finally unhide this command. (See #3386 for context.)

For instance, examples/templates/docker now uses workspace ID in the home volume name and additionally ignores all lifecycle changes, so there should be no situation where a user volume based on it (using todays template) is lost.

I've expanded the warning a bit:

WARNING: A rename can result in data loss if a resource references the workspace
name in the template (e.g volumes). Please backup any data before proceeding.

See: https://coder.com/docs/coder-oss/latest/templates/resource-persistence#%EF%B8%8F-persistence-pitfalls

> Type "test" to confirm rename:

Thoughts?

@mafredri mafredri self-assigned this Dec 19, 2022
@mafredri mafredri requested review from a team, deansheather, bpmct and kylecarbs and removed request for a team December 19, 2022 12:38
Copy link
Member

@deansheather deansheather left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be nice if we could parse the template and detect potential issues like this.

@mafredri
Copy link
Member Author

It'd be nice if we could parse the template and detect potential issues like this.

I totally agree! It seems like a hard problem though, at least if we want to ensure that we only trigger a warning for volumes. We could maybe detect that a mutable identifier is used somewhere, but we won't know what it means. Depending on provider, it could simply be metadata which does not flag the resource for re-creation. We could of course do this for known providers, but AFAICT, it'll never be both safe and discrete (either we miss sometimes or we're very annoying) 😕.

@mafredri mafredri merged commit a7e8f98 into main Dec 19, 2022
@mafredri mafredri deleted the mafredri/feat-unhide-rename-command branch December 19, 2022 20:11
@github-actions github-actions bot locked and limited conversation to collaborators Dec 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants