VMs not redeploying to specified region

1

We recently updated the region of our app to fra:

➜  ~ fly regions list -a staxcloud-staging
Region Pool:
fra
Backup Region:

But the VMs still are in AMS, they are not changing:

staxcloud-staging at: 09:25:37

App
  Name     = staxcloud-staging
  Owner    = staxxer-848
  Version  = 136
  Status   = running
  Hostname = staxcloud-staging.fly.dev
  Platform = nomad

Instances
ID      	PROCESS  	VERSION	REGION	DESIRED	STATUS 	HEALTH CHECKS     	RESTARTS	CREATED
68b97c21	worker   	136    	ams   	run    	running	                  	0       	2022-09-03T12:25:14Z
a5678a8d	web      	136    	ams   	run    	running	1 total, 1 passing	0       	2022-09-03T12:24:55Z
c7dc6ec3	scheduler	136    	ams   	run    	running	                  	0       	2022-09-03T12:24:15Z
2

I believe the region pool affects new vms. So you may need to deploy a new version and then those new vms should be started up in fra. Assuming there is sufficient capacity etc. And the old ams ones would then go away.

3

Hi Greg,

Thanks for your reply. This would make sense, but we’ve been deploying all day. Lots of new VMs have been created and they still get created in ams

1 Like
4

I just tried this for another app:

fly regions set fra

and it immediately removed the old VM and creates a new VM in the new region

1 Like
5

Ah … Strange.

If your other app is able to add its vms in fra, doesn’t sound like a capacity issue either. Which would be my other guess for why new vms aren’t created in a particular region. Alas, one for Fly to debug.

1 Like
6

This looks like a multi-process app. Do you have [processes] set in your config here? If so, you’d want to invoke fly regions set fra --group $name

1 Like
7

Right, this was it. So in what way does this behaviour make sense or is this just one of the rougher edges of the multi-process feature?

8

It could absolutely be better documented that regions set takes a group argument :sweat_smile: !

I suppose it’s an extension of the flexibility in provisioning resources that you get with multi-process apps.

9

Wouldn’t it make more sense to see it as a filter? E.g. fly regions set fra changes the region for all processes. fly regions set fra --group web changes the region only for the web process.

1 Like
10

Yeah, that makes total sense, but I don’t have an ETA for this right now. We’ve recently been talking about ways to make using multi-process apps easier, and so I’ve brought this up in that conversation. Yesterday, we also added some validation in the API that will at least make it clearer when the --groups flag is needed.

2 Likes