This worked flawlessly, both for some of my Telegram bots, and for my Laravel website. And it was really quick!
this breaks fly without the builder, just pulling images from github :c
i have to manually replace the image name
Strange, just did another bot, and it did not create a machine at all. Just migrated and said it was done, and updated fly.toml. Deploying manually to see what happens.
Ok, that did it. However it seems like it spun up two machines, and paused the one. Not sure what happened there.
Should also point out that the dashboard is persistently slow. Also getting HTTP 502s and 500 quite often. I opened another post about that prior to upgrading.
I have an application that consumes a RabbitMQ queue.
A few weeks ago, I migrated it from v1 to v2 using the fly migrate-to-v2. However, I have noticed that the v1 application is still running despite the migration. Although I can stop the VM using the fly vm stop, a new instance will start shortly afterward. Is there any solution to completely stop the v1 application from running?
On the monitoring page, I can view both v1 and v2 instances simultaneously.
I updated my app and now I see this nagging message. How do I disable it? I can ublock it but I’d rather just dismiss it.
And another thing: V1 apps show memory, instance size, and cpu. V2 doesn’t show this info. Is this intended?
@valk just letting you know that this bug is fixed! Sorry it ate your [build] section
@miker was the app live when you migrated? Regardless, I’m glad you got it working!
As for the dashboard - yeah, there was a bit of backend slowness the past couple days.
@Marco oh no, that’s really not supposed to happen. Off the top of my head, you might be able to solve this with
fly apps set-platform-version detached && fly scale count 0 && fly apps set-platform-version machines
If that doesn’t work, I’ll be happy to take a deeper look at this.
@nukeop That view doesn’t really work conceptually for Apps V2 because individual machines can have different configurations, whereas on V1 there was a single VM size that every VM shared.
The closest thing we have right now is the flyctl command fly scale show - this is an area where there’s definitely room to settle on a better UX.
1 Like
@allison It worked, thank you!
1 Like
I had scaled it to 0 as it’s a bot that uses long polling, limited to one connection at a time. I did this with a different bot, and was quite sure that it spun up a machine automatically.
With the dashboard, it’s been like this since I signed up, but not as bad as it has been of late (intermittent).
A couple more things:
-
How do I disable the nagging message about deploying on two instances? I only need one. I never got an answer to this question.
-
When I’m deploying a service, I’ve noticed that it now creates a second instance by default, even if not asked to. It says so int he terminal, but the message is easy to miss and it’s deceptive, as it multiplies the cost by a factor of 2. I get it that you want to sell us more, just raise the prices and be transparent about it instead of pushing this onto us in an underhanded way like this.
For some services I’m running, and I imagine this is the case for most users, running more instances is useless or even actively harmful if they’re not written in a way that enables that. For example i’m running a chatbot that is in no way adapted to run on 2 servers at once, it would log in twice and answer questions twice if I hadn’t noticed that fly added another instance without being asked to.
- When I’m scaling down to 0, I lose all the settings and have to deploy the app from scratch. I used to be able to just run
flyctl scale count 0when I no longer needed an app temporarily, and then it only tookflyctl scale count 1to bring it back up within seconds. Now I can’t do that; I have to redeploy the entire app, and then set the ram and cpu again, and it takes a much longer time. I’m getting the feeling that this is another way to force users to keep using (and paying for) resources they don’t need, by introducing friction when you try to manage your machines efficiently
I get it that you want to sell us more, just raise the prices and be transparent about it instead of pushing this onto us in an underhanded way like this.
I wish that was what we actually intended to with that extra machine.
To answer your question, add --ha false flag to your fly deploy command to disable automatic high availability. Read more on the 2 machines behaviour here.
For some services, running more instances is harmful if they’re not written in a way that enables that.
This is true & good feedback. I guess there’s an improvement to be made here.
Fwiw though, once the autoscaler kicks in, it stops all machines that aren’t serving any traffic. So you pay nothing if no-one is using your machine.
I’m getting the feeling that this is another way to force users to keep using (and paying for) resources they don’t need, by introducing friction when you try to manage your machines efficiently
You’re getting the wrong feeling.
When I’m scaling down to 0, I lose all the settings and have to deploy the app from scratch. I used to be able to just run
flyctl scale count 0when I no longer needed an app temporarily, and then it only tookflyctl scale count 1to bring it back up within seconds. Now I can’t do that; I have to redeploy the entire app, and then set the ram and cpu again, and it takes a much longer time.
I think you might have encountered a bug. That sounds like wrong behaviour. Gonna try and reproduce it.
I’m fine with paying. Just collect my bill even if it’s under $5. I think it’s very generous to let me test out stuff and even run production services for free, but I’d rather pay the full, true cost in dollars instead of being nudged towards wasting resources I don’t need. At this point I genuinely believe this is not your intention and hope it stays that way. Thanks for your tips.
Hi, I deploy my app with github action
I assume that after migrating to the V2, all my deployments with Github action will automatically use the V2 app?
It should work the same! There’s two caveats here, though
-
If you keep the
fly.tomlfile in your repository, you’ll want to make sure to commit it after you migrate. Sometimesmigrate-to-v2makes tweaks to your config to better match the features between v1 and v2. -
If you’ve pinned a specific version of flyctl in your CI pipeline, you’ll probably want to update that to a more recent build of flyctl (as of writing, the most recent version is
0.1.4).Unlike V1, where flyctl was essentially a thin client over our API and all the magic happened server-side, V2 is based on flyctl reading your app’s config and producing/updating corresponding machines, pretty much all client-side. Because of this, flyctl updates play a much larger role in bugfixes and feature additions than they did before. Even in just the past two months, quite a few V1 features have been ported to V2 apps, basically all through updates to flyctl.
1 Like
Request: allow app name as a config flag so the fly.toml file is not required.
I am getting this error for an older app:
Error: input:3: createRelease Validation failed: Image is not allowed for app
@danwetherald what app were you attempting to migrate? We’re aware of an issue with some apps using an old style for the image ref but want to make sure this isn’t a new variant.
Hi @JP_Phillips, sure here are the 3 that saw that error referenced above:
better-cart-events
better-cart-clicks
better-cart-clicks-api
What is the best way to migrate these without creating a new app or re-deploying?
Thanks,
Ok, we’re aware of this issue. It has to do with the image reference and we’re working out a way to support it somehow. If you want to migrate before we have a change in place, you’d need to first re-deploy with a new/fresh image and then you should be able to perform the migration.
Thanks @JP_Phillips - any idea if the solution will be out before the automatic v2 migrations run?