Prevent destroying and recreating home volume on workspace update

Using this example template: https://github.com/coder/coder/tree/main/examples/templates/do-linux

When I make a change to

cloud-config.tftpl

cloud-config.tftpl

, the volume that houses my user's home directory gets destroyed and recreated each time I update the workspace to the newest version of my template.

How can I prevent this? I'd like to be able to push a new version of the template that, say, installs some additional program, and have the user be able to update their workspace to the new version without blasting whatever the user was working on in their home directory.

GitHub

coder/examples/templates/do-linux at main · coder/coder

Remote development environments on your infrastructure provisioned with Terraform - coder/examples/templates/do-linux at main · coder/coder

kyle•10/7/22, 9:23 PM

You can use the Terraform built-in: https://www.terraform.io/language/meta-arguments/lifecycle#ignore_changes

Terraform by HashiCorp

The lifecycle Meta-Argument - Configuration Language | Terraform by...

The meta-arguments in a lifecycle block allow you to customize resource behavior.

Mr_NeezerOP•10/7/22, 9:31 PM

takes an array... what values should I be populating that with? Using the example template linked above... can't figure out what values to put in there.

Mr_NeezerOP•10/7/22, 9:42 PM

When I push my template update, I see in the output... if I understood why Terraform plans to create it, I imagine I could use that value in , right? Is there a way to get Coder/Terraform to print that information somehow?

Apologies if that's a stupid question; still very new to Terraform.

kyle•10/7/22, 9:43 PM

All good! will probably do it

Mr_NeezerOP•10/7/22, 9:44 PM

Do I need to pair that with , or is good enough on its own?

kyle•10/7/22, 9:44 PM

should be good enough on its own

Mr_NeezerOP•10/7/22, 9:46 PM

Ok, trying to push a new template with that change... will report back in a few minutes.

Mr_NeezerOP•10/7/22, 9:51 PM

Hmm, no joy. I added that inside the resource block for ... is that the right location?

Mr_NeezerOP•10/7/22, 9:51 PM

The log output when pushing the template still says and the volume is destroyed/created when updating the workspace.

Mr_NeezerOP•10/7/22, 9:52 PM

This is what it looks like right now:

Mr_NeezerOP•10/7/22, 9:54 PM

... or should I be putting that in instead? Just now noticing that is listed as a resource dependency there...?

kyle•10/8/22, 12:42 AM

It's weird that's recreated... I guess try that for the project resources hmm

Mr_NeezerOP•10/10/22, 4:26 PM

@kyle Hey, circling back to this... I tried relocating the call to project resources, and no difference.

Would it be helpful to post my in a gist in its entirety so you can see the whole thing? I'd really like to get this figured out.

kyle•10/10/22, 4:48 PM

Yup, I'm happy to help!

Mr_NeezerOP•10/10/22, 7:11 PM

@kyle Thanks! Here's the gist for : https://gist.github.com/neezer/82a0b4b74bce54d73b24b7d6c2ad71d2

Gist

do-droplet Coder template

do-droplet Coder template. GitHub Gist: instantly share code, notes, and snippets.

kyle•10/10/22, 7:13 PM

Could you share the Terraform output as well?

Mr_NeezerOP•10/10/22, 7:13 PM

Sure, one sec

Mr_NeezerOP•10/10/22, 7:14 PM

Gist updated to include Terraform output.

Mr_NeezerOP•10/10/22, 8:06 PM

@kyle ^^

kyle•10/10/22, 11:27 PM

Ahh ty

kyle•10/10/22, 11:27 PM

So on template push you'd expect a home volume to be created, right? Could you send me the output from a workspace create and stop/start please?

Mr_NeezerOP•10/11/22, 12:00 AM

So on template push you'd expect a home volume to be created, right?

No, I don't think so. I think I'd expect a new volume to be created only on workspace create.

Could you send me the output from a workspace create and stop/start please?

Yeah, I'll add it to the gist in a bit. I'll ping ya here when it's up.

kyle•10/11/22, 12:04 AM

So resources are never created on template push, they are just planned.

Mr_NeezerOP•10/11/22, 12:09 AM

That's my understanding, yes.

kyle•10/12/22, 5:44 PM

@Mr_Neezer following up on this, in the gist it doesn't show the home volume being deleted on stop.

Mr_NeezerOP•10/12/22, 5:58 PM

@kyle Thanks for the follow-up! Sorry, been busy trying to figure out this automatic CSR issue... I've been testing whether or not data persists by creating a text file with some random string in my home directory, then start/stopping the instance. When I log back in using the Terminal and/or SSH, the file is gone.

Mr_NeezerOP•10/12/22, 5:59 PM

I still owe you logs for start and create; once I get my recent CSR changes sorted, I'll update the gist and ping you with those too.

Mr_NeezerOP•10/13/22, 5:58 AM

@kyle Ok, gist is updated with command output from create, stop, and start. has also been updated to show my latest setup.

Additionally, the mounts section in my cloud-init looks like this:

My primary test is this:

SSH into the workspace. Run
Stop the workspace.
Start the workspace.
-> cat: test.txt: No such file or directory

Additionally, it appears all my initial provision scripts are re-run each time I stop/start as well. Any ideas what I'm doing wrong here?

Mr_NeezerOP•10/13/22, 3:50 PM

@kyle I see the following in the stop/start logs:

digitalocean_volume.home_volume: Drift detected (update)

Could that be related? What does Terraform consider "drift?"

kyle•10/13/22, 3:55 PM

So it's not recreating it based on the output. Are you certain it's being mounted correctly?

Mr_NeezerOP•10/13/22, 3:56 PM

I didn't change anything from the example template for as far as mounting goes (at least, not to my knowledge). Is there a way I can diagnose whether the mount happened successfully or not?

kyle•10/13/22, 3:56 PM

Try typing inside a workspace to see.

kyle•10/13/22, 3:56 PM

And toss the output in here

Mr_NeezerOP•10/13/22, 3:57 PM

message.txt2.03KB

kyle•10/13/22, 3:58 PM

Seems like the home volume isn't being mounted for some reason. Try catting the logs in

Mr_NeezerOP•10/13/22, 3:58 PM

Yeah, looks like it. One sec, catting the clout init logs...

Mr_NeezerOP•10/13/22, 4:00 PM

cloud-init.log126.86KB

Mr_NeezerOP•10/13/22, 4:01 PM

Oo:

Stderr: mount: /home/evan: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error.

kyle•10/13/22, 4:01 PM

Welp, interesting

Mr_NeezerOP•10/13/22, 4:02 PM

I pasted the section of cloud-init further up this thread, if you missed that.

Mr_NeezerOP•10/13/22, 4:03 PM

Didn't change that from the example repo, though.

kyle•10/13/22, 4:03 PM

Hmm, it's not impossible that ours is outdated.

Mr_NeezerOP•10/13/22, 4:04 PM

True.

Mr_NeezerOP•10/13/22, 4:05 PM

I opened up the volume in my DO dashboard, and see this for config instructions:

Do those options in jibe with what I'm doing in the section of cloud-init?

kyle•10/13/22, 4:07 PM

I think so... but maybe instead of

auto

auto

lets explicitly put ?

Mr_NeezerOP•10/13/22, 4:07 PM

Ok, giving that a try.

kyle•10/13/22, 4:08 PM

You can try running to do it manually

kyle•10/13/22, 4:08 PM

But that should essentially be the same as the clout init

Mr_NeezerOP•10/13/22, 4:12 PM

Interesting. That didn't work, but the error in cloud-init logs changed:

Stderr: mount: /home/evan: can't find LABEL=coder-home.

That might be related to a change I tried last night, which was to try to use the attribute instead of the attribute. Lemme put that back and try again.

Mr_NeezerOP•10/13/22, 4:15 PM

While I'm waiting for that to rebuild, an adjacent question: for cloud-init, am I guaranteed to have the mounts resolved by the time I reach the and/or sections? Or is the order not guaranteed?