new machine/volume is created with random settings, without my consent

[sekao]

My app only has a single process, and my existing machines are part of the default “app” process group. However, when I made a new machine in a different region, it is showing up with no process group at all. When I run fly machine list, my old machines have “app” under PROCESS GROUP, and the new one has nothing there. How do I add the new machine to the “app” process group? When I do deploys, it does not update the new machine.

EDIT: As you can see below, I recreated all of my machines and now all of them have an empty process group. But now when I deploy, fly can’t find any machine, because it wants to deploy to the “app” process group. Instead of giving me an error, it creates a brand new machine and volume with random CPU and disk space settings. There is no way I could build a business on a platform that does this kind of magic:

[WARNING] Your app doesn't have any Fly Launch machines, so we'll create one now. Learn more at 
https://fly.io/docs/launch/

Creating a 1 GB volume named 'foobar' for process group 'app'. Use 'fly vol extend' to increase its size
This deployment will:
 * create 1 "app" machine

[halfer]

May we see your TOML config file?

[sekao]

Sure, here it is:

# fly.toml app configuration file generated for foobar on 2023-09-15T15:40:31-04:00
#
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
#

app = "foobar"
primary_region = "dfw"
kill_signal = "SIGINT"
kill_timeout = "5s"

[experimental]
  auto_rollback = true

[[mounts]]
  source = "foobar"
  destination = "/data"
  processes = ["app"]

[[services]]
  protocol = "tcp"
  internal_port = 8080
  processes = ["app"]

  [[services.ports]]
    port = 80
    handlers = ["http"]

  [[services.ports]]
    port = 443
    handlers = ["tls", "http"]
  [services.concurrency]
    type = "connections"
    hard_limit = 25
    soft_limit = 20

  [[services.tcp_checks]]
    interval = "15s"
    timeout = "2s"
    grace_period = "1s"

[[services]]
  protocol = "tcp"
  internal_port = 2222

  [[services.ports]]
    port = 22
  [services.concurrency]
    type = "connections"
    hard_limit = 25
    soft_limit = 20

  [[services.tcp_checks]]
    interval = "15s"
    timeout = "2s"
    grace_period = "1s"

[sekao]

I remade all my machines, so now all of them are blank under “PROCESS GROUP”. This did not fix the problem. In fact, now when I fly deploy, it says it can’t find any machines, and (unhelpfully) creates a new machine and volume with randomly-chosen settings without even asking me first…

[WARNING] Your app doesn't have any Fly Launch machines, so we'll create one now. Learn more at https://fly.io/docs/launch/

I don’t want to belabor this point, but how is it appropriate to randomly create a new machine with random settings like this? Shouldn’t it just give me an error and ask me to fix it? I still don’t know how to add a machine to the “app” process group, but I’d rather just get an error instead of having machines/volumes randomly created for me that I am paying for.

[halfer]

I don’t have a particular idea what is going on in your case, but I can continue to give some ideas. Firstly, could you do flyctl deploy --verbose to see if there are any clues there? Paste the output here.

Also, is your fly.toml in the project root? The behaviour you describe makes me wonder if the binary is not seeing your configuration.

[sekao]

It is in the project root, yes. I’ll try the --verbose flag when I get the chance, but it’s quite a pain right now, because it is randomly creating a machine and volume every time I run the deploy command, and it takes a long time to delete them. I really am not a fan of this kind of “magic”…just give me an error and tell me to fix it. Making a new machine and volume like this is kind of shocking. I don’t mean to direct this at you – you’ve been very helpful.

[halfer]

You can always create a new app, and then you can experiment safely.

I should note that Fly employees usually have a purple parachute on their profile image, and they often help here. I however do not work for Fly; I am just a customer with a side-interest in helping fellow engineers. I think the core Fly product is very good, but they’ve a little way to travel in terms of intuitiveness and reliability. I think they’ll get there.

[catflydotio1]

Hi @sekao, are you combining “Fly Launch” features (fly launch, fly scale, fly deploy etc.) with manual creation of Machines (with the API or with fly machine run)?

The reason I ask is that Machines created with fly machine run are treated as separate from an app’s deployment. They don’t get a process group, don’t use fly.toml for configuration and are not affected by new deployments. If fly deploy doesn’t find any Machines that it “manages”, it considers the “app” to have no Machines—which looks like a newly created app—and creates at least one new one.