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
What happened?
So if the client happens to need to reinstall (due to system failure or similar issues) there is no way to re-import an already existing project on a remote machine. An attempt to re-create the project will in fact make devpod delete the currently existing data, meaning if you were not using git, or had unstaged changes those files are now gone and devpod will now try to re-upload the files what you currently have, and because devpod does not sync file changes down, you end up with lost progression.
What did you expect to happen instead?
I would expect devpod to figure out if an already existing project with the same name exists, and if so, ask the client if they would prefer to use it, or change the workspace name to something else. I also think that when an ssh provider is added, it should go ahead and check if any workspaces already exist on the provider and import those workspaces for the client so they can just continue.
How can we reproduce the bug? (as minimally and precisely as possible)
Add ssh provider
Create workspace with a fixed name, and point it to a folder (so files are uploaded)
Run workspace (just so everything works)
Uninstall devpod (and delete any data related to it)
Reinstall devpod
Go through steps 1 & 2, and you'll see in the logs that it sees a project with the same name and deletes it
Local Environment:
DevPod Version: 0.6.4
Operating System: linux
ARCH of the OS: AMD64
DevPod Provider:
Local/remote provider: docker | ssh
Anything else we need to know?
This might need to be another issue, but when you create a workspace using ssh, devpod sometimes fail to create a workspace due to permission issues.
The text was updated successfully, but these errors were encountered:
Thanks for raising your issue @ADRFranklin. Devpod persists the workspaces in your local folder ~/.devpod. When you uninstall devpod and delete the data, there is no way for it to know about any existing workspaces on any target. When you say So if the client happens to need to reinstall (due to system failure or similar issues) I'm not quite sure I follow why you need to do this? If you uninstall devpod all data will be lost. If you have a workspace failure, I would instead recommend simply running devpod up {name} to restart the devcontainer. There shouldn't ever be a need to re install devpod. Let me know if that helps!
When you say So if the client happens to need to reinstall (due to system failure or similar issues) I'm not quite sure I follow why you need to do this?
Recently I had a system failure and was unable to fully recover (lost all local files). I made the assumption that my data would be okay since it was on a remote machine, however I almost lost the changes (I ssh'ed in to the remote machine and backed up the .devpod folder), because I was not aware that reinstalling and re-creating the workspace would in fact delete my remote data (though backing up the folder was just something I did just in case). Devpod didn't warn me the data would be deleted and just went ahead and deleted it, if anything a confirmation should be given or some other way to handle that with user input.
There shouldn't ever be a need to re install devpod.
I would say that for most applications, however sometimes you are forced to, because of weird linux things. Sometimes it is unavoidable.
Would it not make sense to store some data on the remote to help with recreating the workspace? As if anything goes wrong on the client, it is then expected that all data is lost from that point on, which seems dangerous. I just think more measures should be in place to safe guard the data.
One question I do have is, is there a way to manually re-create the workspace locally in a way were devpod skips uploading folder data, and that and treats the workspace as if it's already been initialised? I would prefer this method for now, since there isn't currently a way to continue a workspace.
What happened?
So if the client happens to need to reinstall (due to system failure or similar issues) there is no way to re-import an already existing project on a remote machine. An attempt to re-create the project will in fact make devpod delete the currently existing data, meaning if you were not using git, or had unstaged changes those files are now gone and devpod will now try to re-upload the files what you currently have, and because devpod does not sync file changes down, you end up with lost progression.
What did you expect to happen instead?
I would expect devpod to figure out if an already existing project with the same name exists, and if so, ask the client if they would prefer to use it, or change the workspace name to something else. I also think that when an ssh provider is added, it should go ahead and check if any workspaces already exist on the provider and import those workspaces for the client so they can just continue.
How can we reproduce the bug? (as minimally and precisely as possible)
Local Environment:
DevPod Provider:
Anything else we need to know?
This might need to be another issue, but when you create a workspace using ssh, devpod sometimes fail to create a workspace due to permission issues.
The text was updated successfully, but these errors were encountered: