My app (cave-demos) was stick at “Unpacking image” during the deploy process.
I deleted the app and recreated (seems like there’s no way to initi an application with an existing config?) which solved the build issue. At this point, for some reason, the app was unavailable at https://cave-demos.fly.dev
Assuming it was a stale cached route, I redeployed to “cave-demo.fly.dev” and everything worked!
Although now, when I redeploy that app I’m stuck at “Unpacking image” again.
huh! looks like community.fly.io is hosted on fly.io and when the discourse instance crawled my app I got an ipv6 request ip! that’s a first for me
[GIN] 2021/01/18 - 18:00:20 | 200 | 156.493µs | 2001:470:14e:5:0:274:2edb:fac | GET "/"
You can run fly init newappname --import fly.toml and flyctl will try to init the new app and the config in fly.toml and put them together for you. It’ll ask if you want to overwrite fly.toml - you can say yes as its completely read in before it writes the new one out.
@Codepope ah, I did not read the command line options closely enough, thanks!
Freezing on “Unpacking Image” seems to have stopped in the latest deploy.
We’re debugging that “Unpacking image” freeze. It’s happening on one particular host that we’ve temporarily disabled.
This just happened to me – “Unpacking image” took 5 minutes to finish.
2022-03-01T17:00:23.856 runner[dc29f38c] yyz [info] Starting instance
2022-03-01T17:00:23.935 runner[dc29f38c] yyz [info] Configuring virtual machine
2022-03-01T17:00:25.594 runner[dc29f38c] yyz [info] Pulling container image
2022-03-01T17:02:38.373 runner[dc29f38c] yyz [info] Unpacking image
2022-03-01T17:07:01.318 runner[dc29f38c] yyz [info] Preparing kernel init
2022-03-01T17:07:09.085 runner[dc29f38c] yyz [info] Configuring firecracker
2022-03-01T17:07:09.145 runner[dc29f38c] yyz [info] Starting virtual machine
There was a surge of instances scheduled in YYZ. When that happens, it makes unpacks slower. Investigating.
Turned out to be abuse. We’ve fend them off for now.