Hi Allison! Happy to talk about it, and thanks for the fast reply.
I’d consider this expected - the scale commands don’t really save any desired state […]
Interesting. I’d say maybe it is less surprising to a Fly’er or someone knowing this detail, but still surprising to us. It’s a bit different than other orchestration environments we know (ecs, k8s, cloud run, heroku). In those places, when you configure a static scale of
N doesn’t change without you asking!
May I ask what you’re trying to do? I want to see if there’s another way to get the same result, and if not, I’ll look for some way (probably command line flags!) to make flyctl support this usecase.
Definitely! Actually have two examples.
Example 1: We’re working to bring more of our infra over to Fly (yay!), while also making the fewest changes to how our services are structured. In other words we don’t want to refactor anything now “just for Fly” if we can avoid it.
One service we’re bringing over, from Heroku, has 3-4 process groups over there. One process is our main dashboard, and another is a job queue. We want to be able test the appserver on Fly without the job server spinning up and taking over production jobs. So the idea was to set “scale=0” on that process.
For now, the workaround is to comment out the process group.
Example 2: We have a staging environment with the same complement of process groups. However because staging usage is bursty, we’d rather not leave machines running that we’re not using.
In particular, one process (in prod) listens forever on an open websocket, so scaling to zero when idle can’t be used here. In staging, this process is usually irrelelvant - unless we’re testing something related to it.
So the problem is, a general re-deploy to staging is going to gratuitously bring the
listener process back up, until someone notices and scales it back down - which is basically the workaround I have right now.
Thanks for listening and any suggestions!