Hey here, Apps v2 (Machines) includes a lot of really cool changes that have been useful to me, but I’ve also run into a lot of issues with Volumes, and the following is a list of the issues that exist now.
In fact, we can create a volume as described in the Volume documentation, but this is under the app scope and not connected to machines, which can be very confusing for new users, so why can I create a volume and not show it on the machine?
When using machine, we may need to use other ways to connect to Volume, but this should be marked in the documentation, as it is completely different from the behavior of v1, where we only declare source in the
fly.toml file to connect. (I guess someone may be stuck here.)
If you have deployed a machine once and it starts successfully, and then you create a Volume under the App, it is not possible to connect them via
fly machine update, because a running machine cannot update the Volume.
$ fly m update <id> --volume <volume_name>:<path_name> > failed to update VM <id>: unable to add volume after machine is created
Even if you stop the instance (
fly m stop <id>), you cannot update the configuration of the Volume.
update command doesn’t support
--volume, it shouldn’t be listed in
--help, which is very confusing. Perhaps some other temporary factor is suspending this command?
To add Volume to Apps v2, we have another way to bypass
fly m update, which is to clone an identical machine but add an additional
fly m clone <id> --attach-volume <vid>
Although you were able to successfully create a machine with the same configuration, note that this machine does not contain Volume, and the
--attach-volume command does not actually work or even throw an error.
Now, another way to add Volume to Apps v2 is to preboot a machine with Volume using the
fly m run command and then redeploy (or tune) the application.
$ fly m run . -v <vid>:<path> --region <volume_region>
It looks good now, I created a machine in the same region as Volume and successfully added Volume to the machine.
However, machines created by
fly m run will be automatically destroyed by an error when deployed using
deploy will immediately kill machines that are not started by the app process group.
So we also need to add additional metadata for the machine:
$ fly m update --metadata fly_platform_version=v2 <id> $ fly m update --metadata fly_process_group=app <id>
Please note that although we appear to have specified both
target_path, we have actually only modified
volume_id), so the following configuration needs to be added to the
fly.toml file again for it to work properly:
[[mounts]] destination = "<pathname>"
Well, it’s finally working. But be careful, if you ever accidentally destroy or rebuild a machine, it will all have to start all over again.
I don’t think anyone other than the Fly staff has used Apps v2 (with Volumes) correctly, it’s a terrible development experience where we have to guess at the developer’s intentions from all the error messages and guess at how the parameters work from the fragmented documentation.
Fly is a good platform, and everyone here will agree, but I think Fly’s commitment to documentation and testing is too low, and developers should be using cloud services with a smile on their face, not spending their days guessing how fly’s engineers think.