Fly Scale Count ignores the value of --vm-* options when sizing a machine

[swilson-fly]

Describe the bug
Briefly, describe what broke and provide the following details:
The fly scale count command takes the --vm-* family of flags (vm-size, vm-cpus, vm-memory etc.) which are used to specify the sizing of the newly created machines. However it seems to disregard this input altogether, creating machines that are the same size as the existing ones.

For example on an app with a shared-1x machine, running fly scale count 2 --vm-size 'performance-2x' will add another shared-1x machine. This is in contrast to fly machine clone which handles those flags correctly, creating a machine of the specified size.

• Operating system
• fly version
  fly v0.2.126 darwin/arm64 Commit: c44f26f BuildDate: 2024-09-06T21:32:23Z

** Paste your fly.toml

n/a

** Command output: **

fly scale count web=4 --vm-size 'performance-1x'
App 'floral-cherry-***' is going to be scaled according to this plan:
  +1 machines for group 'web' on region 'iad' of size 'shared-cpu-1x'

fly scale count web=5 --vm-cpu-kind='performance' --vm-cpus 1 --vm-memory 2048
App 'floral-cherry-***' is going to be scaled according to this plan:
  +2 machines for group 'web' on region 'iad' of size 'shared-cpu-1x'

[dangra]

This is a recurrent issue. I would like to share some context on why it works that way, and what things have to be kept in mind if we change it. Hopefully we can come up with a workflow that works for everyone.

Historically to change the size (mem, cpu, ...), or scale vertically, you have to use fly scale vm or the more specialized subcommand fly scale memory. fly scale count is exclusively to scale horizontally and only adds or remove machines, it doesn't update existing ones. The --vm-* flags on fly scale count were introduced as a workaround when there is no existing machine for a process group and fly.toml doesn't define with a [[vm]] section.

It doesn't have to stay way of course but if we allow fly scale count to change existing machines:

• it has to issue warnings that next deploy will override the vm size if a [[vm]] section is present in fly.toml
• it could be very aggressive restarting machines unless it consider rolling strategies, health checks and so on
• In general I'd say it is much better to run fly deploy with an updated [[vm]] section than scaling vertically with fly scale commands.