How to get app to run in same region as volume

I created my app to run in dfw. I created a volume in dfw. When I list volumes, it shows it in dfw.
But when I fly status, it currently shows jnb. Was originally dfw. A couple times after a deploy it was sin. But now it is jnb. So I cannot connect my volume - if I try to do a deploy with the volume specified in mounts section of fly.toml, the deploy hangs indefinitely. I assume because it cannot find the volume in the region it is trying to deploy to.
If I try fly regions set dfw to re-assert that the app should be in dfw, it gives me the unhelpful error:
Error App ‘myapps’ uses volumes to control regions. Add or remove volumes to change region placement.

What exactly is meant by "“Add or remove volumes”? I’ve created a volume. Is that what it means? I’ve tried adding the mount of the volume, but as mentioned, that causes the deploy to fail.

Hi @joshf, thanks for reporting the stuck deploy. There was a capacity-related issue on a host in dfw that might have been causing your mounted-volume deploy to hang. I’ve unblocked the host so your deploy should now complete as expected.

As for the other issue, it sounds like the app with an un-mounted volume deployed in random regions, is that correct? That might be an edge case with undefined placement behavior. Usually, either an app uses a mounted volume to ‘anchor’ region placement, or an app sets region constraints through fly regions. Either mount the anchor volume, or delete it and then fly regions set should work again.

1 Like

Thanks @wjordan - yes the app is deploying to random regions - when I remove the [mounts] clause.

I tried adding the [mounts] clause again, and it causes my deploy to hang indefinitely. I’ve got one running right now - and has been for at least 5 minutes. Maybe I’m being too impatient? Should I expect a deploy that attaches a volume to take many minutes? (usual deploys of my app are about a minute)

Ok, I see my deploy finished about 15 minutes ago. So it took about 45 minutes to deploy with the volume attached. Maybe I was impatient, and that is expected? Or maybe someone intervened to fix the stuck deploy.

I took another look this morning and found one more change I had to apply in order to unblock the host for your volume-mounted deploy to proceed, so it should now work correctly (and please let me know again if it still doesn’t!).

In general, deploys should not be in the pending state without any app-initialization activity for more than 5-10 minutes or so- if it takes longer than that, it’s possibly either an internal infrastructure issue or a host/region is hitting capacity limits. Volume-mounted apps are a bit more sensitive to single-host issues because the volume is created on a specific host and so the app is required to deploy there. In any case, please let us know if it happens again and we can take a look.

1 Like