I have initial_size for a volume mount defined in my TOML file.
The documentation suggests that this settings is used when fly deploy needs to create a new volume. Based on my experimention, however, I think this is incorrect or misleading.
I’ve been scaling up my app with fly scale count and I noticed that even when the scale-up needs to create a volume, it will create it with whatever the initial size was for the existing machine as opposed to what’s in the TOML file that we deployed last.
So, for example, if I deployed an app with one machine without the setting set, it will get a 1GB volume. If I then add initial_size = 2, redeploy, and scale up, the new volume will still start out at 1GB. Only if I fly scale count 0 and then scale up, will I get a 2GB volume.
I’m assuming this is because scaling up actually just “clones” an existing machine. If so, could the docs be clarified on that point.
Also, is there an officially recommended method for scaling up machines with volumes larger than the initial deploy without first taking everything online? The only thing I can think of right now is to manually provision the new volumes so that fly scale count doesn’t have to create them.
Hi… Glancing at the source code, it’s heuristic and not nearly as simple as the above guess; there doesn’t appear to be any single Machine that’s getting selected for cloning, in particular.
It does seem to base the initial size primarily on a fold over the full set of existing volumes, though, and that could definitely be mentioned in the docs, .
This isn’t an official recommendation, of course, but, personally, I think that fly scale is more of a holdover of the old Nomad system, and people are mostly better off using fly vol create, fly m clone, and fly m destroy directly.
Those give you better predictability and more options—for example, starting the new Machine off with a fork of an existing volume.
Hope this helps a little!
Aside: The question of how declarative the Fly.io platform should be in general has long been debated in the forum. Whether things should be chiefly based on config files or chiefly influenced by the state built up through months of imperative flyctl calls in the terminal. It looks like Fly.io themselves are of two minds on this…
Users who have very strong opinions about how updating and scaling should be done in detail seem to gravitate toward writing their own orchestration, via the Machines API.
.