rolling deployment details

[mayailurus]

@ruslandoga1

restarts one machine at a time

Hi… Yeah, the chapter of the docs that you’re reading really does give that impression, , and I think that was how rolling worked for a long time:

@charsleysa

@ignoramous

As one example, flyctl recently switched to staggered group deployment for rolling startegy (which previously, deployed one by one) and there was no announcement. I mean, I like it , but if for some reason, if my prod workflow relied on machines restarting one after the other, I’d be in deep pickle.

They also broke the option for one by one rolling deploys without warning either.
You could use --strategy-batch false but suddenly that disappeared in 0.1.72 and it wasn’t until 2 days later in 0.1.75 that --max-unavailable become available.

Now, though, the default allows it to take as much as 33% of your fleet down simultaneously (presumably geared toward the huge, 1000-Machine customers that Fly.io makes most of its money from).

I would try max_unavailable = 1 and see whether that behaves any better, from your perspective. (That’s the behavior that many others guessed was the default, as well, incidentally.)

Whole number values, greater than or equal to one, specify exactly how many Machines can be down at a time. For example, a value of 1 would update one-at-a-time.

Hope this helps!