How do volumes work in v2 apps?

I just created a v2 app and tried to add a volume.

I ran fly volumes create ....

Then I added:

[mounts]
  source="storage_volume"
  destination="/var/www/html/storage"

When I run fly deploy I get this error:

“machine e784e299cd97d8 [app] does not have a volume configured and fly.toml expects one with destination /var/www/html/storage; remove the [mounts] configuration in fly.toml or use the machines API to add a volume to this machine”

I must be missing something obvious but would love some help with this :slight_smile:

Hi there,

yes, it seems fly deploy is failing when trying to add a new mount and there are machines running already. We’re looking into that.

If you have only one running machine, a solution w/o any downtime would be to manually start a new machine attaching the volume you just created:

fly machine clone e784e299cd97d8 --attach-volume storage_volume:/var/www/html/storage

After that machine is running, you can stop and destroy the previous one:

fly machines stop e784e299cd97d8
fly machines destroy e784e299cd97d8

Now fly deploy should work as usual.

Does that help?

Hi @bruno thanks

Tried it but also doesn’t work:

➜ git:(main) ✗ fly m clone e784e299cd97d8 --attach-volume storage_volume:/var/www/html/storage
Cloning machine e784e299cd97d8 into region ams
Error: Can’t attach the volume as the source machine doesn’t have any volumes configured

I’m not in a hurry, I am just exploring how easy it will be to migrate our apps to v2, and I feel like volumes in v2 are not polished enough yet for me to consider switching those apps :slight_smile:

This community post also describes some of the rough edges, I think it’s worth looking at by Fly team

I migrated a couple apps with volumes yesterday. Since the volumes only containing caches, I tried to avoid downtime by removing them manually, migrating then adding new volumes. I ran into the same problem at the last step.

I found it difficult to understand what to do, and after trying the attach-volume switch (which I couldn’t get to work) and some investigation into the scary-looking machines API I found

So I followed that and scaled them down to 0 (so much for no downtime!), then ran a deploy and it created a new machine with the volume attached. I could then clone it to scale back up. It all seems to be ok now.

@thewilkybarkid Yea this volume thing has some rough edges on v2 :grin: I’ve also talked to Fly email support about this and got this reply:

Believe it or not, this triggered a big discussion internally, and we are working on a better volumes experience – so thank you for that! The situation where a user might want to get from no volumes to one volume is something that we didn’t account for in a good way.

The team is working on some related improvements in the pull requests below.

Replace machines when mounts are added to the process group by dangra · Pull Request #2189 · superfly/flyctl · GitHub
First pass at adding --attach-volume-mount-point by bzanchet · Pull Request #2190 · superfly/flyctl · GitHub

Once things have been stabilized, the documentation should be updated to reflect the processes. I will keep you updated on the progress, as it sounds like you’re looking for volumes with Apps V2 to get more stable before using them in production.

They are working on it :slight_smile:

2 Likes

Thanks, @Yaeger!

Since I’ve only used them for caches, I’m hoping to find a way to remove them entirely:

But if the experience can be improved, that might be less pressing. :slightly_smiling_face:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.