App with multiple processes that are stuck in one region?

I added a cron process to my fly.toml. I deployed it and now my app process is stuck on dfw instead of being deployed in iad.

  1. Added processes to fly.toml
  app = ""
  cron = "cron -f"
  1. Ran deploy
fly deploy --remote-only
  1. Ran fly status and saw app and cron transferred to dfw instead of remaining on iad liked before adding the processes block.

  2. Ran set

fly regions set iad --group cron

Now my cron process is on iad. Ran the same command but with fly regions set iad --group app and my app is still on dfw instead of iad.


fly regions list


Region Pool:
Backup Region:

I tried to scale all the processes to see if the app process would change.

Currently, app is 2 and cron is 1.


fly scale count app=3 cron=1

It scaled the app up, but it’s still in dfw.

I tried to remove processes from fly.toml and now I can’t deploy.

Description = Deployment is running pending automatic promotion.

Removing the processes from fly.toml and now it still thinks that there are processes running.

Error Your app has multiple process groups: app, cron. Please specify a process group to set the region.
1 Like

Are you still experiencing this deployment issue?

I took a quick look at the nomad allocs, and didn’t see any with that deployment description.

I’m having a similar issue where the region is totally ignored, it’s frustrating as it’s causing major performance issues. My database is in iad and the web processes keep booting up in scl??

fly regions list
Region Pool:
Backup Region:

fly status

e3e47aef	streaming	19     	gru   	run    	running	1 total, 1 passing	0       	50m31s ago
9a559470	worker   	19     	scl   	run    	running	                  	0       	1h5m ago
1f137197	web      	19     	ord   	run    	running	1 total, 1 passing	0       	1h5m ago

Hi @tomm,

It’s not clear what you’ve tried, but starting with the simplest possible scenario: the regions need to be set for each process individually, e.g. fly regions set iad --group worker

Yes, it makes no difference :frowning: For my main web instance I was able to fix it by creating a volume that i’m not using in the correct region but worker processes continue to be spawned around the world.

Hi @tomm,

OK. We definitely have a bug with volumes + indeterminate regions.

There’s also something screwy in process groups if you start in one way and then iteratively change your app config. It looks like this may be the issue here. Would it be OK if we remove your volume in order to fix up this job?

Otherwise, you should be able to pin all your processes by giving them all volumes, but that’s probably not what you want to hear.

Yea, volume subculture should be unused now.

Sorry for the trickle, @tomm: can you delete the volume entirely, please?

How I fixed this was to just recreate everything, but in production, I can’t do that.

I ended up feeling like the platform was a nice idea but very unstable for now. It took awhile to get a reply on this thread too.

I did end up moving my infrastructure to another provider.

:white_check_mark: Deleted

Sidenote: I’m surprised it allowed me to delete a volume that was mounted to an instance in use.

@tomm Did you get up and running?

Amazingly yes, all processes are starting in the same region now