Instructions that involve fly machine ... commands are temporary. What’s going away are these commands. They, or something similar, will come back when we figure out the right UX:
fly scale count
fly regions ...
fly autoscale
These cause endless pain, because they don’t behave the way people expect. fly machine clone doesn’t surprise people, and is a decent stand in for now.
i’d argue againt deprecating it, I love these commands, add a region, increase the scale count and autoscale ratio. The main reason I came to fly was because of these commands, you get a hang of it after tinkering with the comands for a while.
I would be fine with something like fly apps scale count [number] [region] that simply does fly machine clone under the hood for me as we have plenty of apps that are ephemeral and don’t care which VMs get created / deleted.
It would be a negative experience to take away fly scale count and have no replacement for it as it’s quite useful for quickly scaling by running a single command. Having to run multiple commands many times in order to get the same functionality is, in my opinion, a step back in developer experience.
@ignoramous when’s the last time you had a lease issue? Are you doing deploys that take longer than 30m? This stuff has all basically been rewritten since December, so pre December behavior has changed.
We’re planning to make fly machine stop <name> work, but not until we get this first release out. Machine IDs actually include routing information, so we know exactly which hardware to send a stop command to. Using names is going to take a little bit of infrastructure work.
That makes sense, though inferring the region will have to work consistently otherwise it could be a jarring experience. I can’t speak too much for multi process apps as we don’t use them (mainly due to limitations around things like internal DNS).
Maybe the distribution of vms across regions could be a config. By default it’s even distribution across all specified regions (e.g. regions: [syd, sin, nrt] and region_placement: balanced results in a scale count of 9 placing 3 vms in each region) but there’s also the option of having per region (e.g. regions: [syd, sin, nrt] and region_placement: per_region results in being able to set the scale count to 5 for syd, 3 for sin, and 1 for nrt.
The last time I tried rolling was in Sep/Oct, 2022. Haven’t tried after.
Thanks for the heads-up. I’ll try again with the latest flyctl and the default strat (rolling) once the builders are up (having trouble deploying right now).
Error failed to fetch an image or build from source: error connecting to docker: You hit a Fly API error with request ID: 01GRDQDGTJMF9QFPXXFNH3EQ61-maa
Gotcha. I was wondering if flyctl can loop through machine names and substitute them for IDs. Back when I was looked at the code last year, it seemed do-able; but the flyctl code base has been through a lot since then.
Update: Kurt, the rewrite has made things better! rolling deploy works just fine for an app with 30+ machines using flyctl-0.0.451.
I contacted billing@fly.io yesterday but didn’t get a response.
So I tried with the CLI but fly machines list says No machines are available on this app so I can’t use fly machines update. Although from the first post on this thread using fly launch should have created a new machine?
Yesterday I used fly v0.0.464 to create the app. I’ve just updated to fly v0.0.473 and will try again.
Edit:
Same result with fly v0.0.473.
Edit:
So I RTFM and tried fly launch --force-machines and then even fly deploy --force-machines. Still no machines…
You’d still get a Nomad (V1) app as of today, unless you used --force-machines with fly launch (or fly deploy, if you didn’t deploy straight from fly launch).
Right now there’s a manual step to enable you to create dedicated VMs. We’re working on making that a smoother experience while keeping a grip on the amount of compute abuse.
Apps V2 doesn’t use region pool. Machines VMs are tied to hardware, so you specify the region for each one. To note: Apps V2 isn’t fully cooked. Bug reports are welcome for unexpected UX!
With the announcement in Make Apps V2 the default for new apps in your org, is there any capability related to appsv2 that requires the flyctl prerelease, or is everything from this post all now available in the mainline flyctl version?
Hi @Alex21! It’s all in the main flyctl release now. If you’re trying out Apps V2 keep an eye on the latest releases because it’s moving fast. Latest as I type is v0.0.482.