Error platform version mismatch: nomad != machines

What does this error mean?

I’m trying to create a flyctl machine with “flyctl machine run”, and getting this cryptic error message.

If you’ve deployed your current app via fly deploy (not using machine), then you can’t launch machines with it anymore. You’ll need a new app unfortunately.

You can specify the app name via fly machine run -a app-name

Thanks! Is there any tutorial/documentation for “fly machine”? I couldn’t find anything on google.

For instance, one other question that comes to mind - how long does cloning a machine take? Does it only clone the configuration or also the data that lives within the machine?

fly machines haven’t been released yet. :slight_smile:

You’re welcome to play with them, but until we officially launch them we won’t have many docs. The clone command might actually go away, it doesn’t do anything special.

@urish are you doing anything in particular with machines? We have a couple of well defined use cases for them when we launch, but we think they’re interesting for a whole lot more.

1 Like

“Serverless. Less VMs than a Nomad. Lame.” :wink:

1 Like

@kurt, you say that clone doesn’t do much. It does seem to “complete” a LOT faster than run. I’m not sure yet if the clone is up and running when the command completes but it would be great if there were a very quick way of spinning up a new instance of an app that does not carry over any state from prior instances.

In my scenario I’d like to have essentially a bunch of “utility apps” the work on behalf of many different users. As it is today multiple requests to the same app seem to reuse a running instance (if one’s available). That can lead to state leaks. I could, in theory, duplicate the set of state apps per user but that math gets to very big numbers very quickly and becomes a management nightmare.

I was hoping that you were using Firecracker snapshots under the covers and that clone we sort of “stamp out another copy of the snapshot”. Either that or that stop/start of a running machine was super fast (e.g., snapshot reset).

Thoughts? Pointers?

Stop / start should actually be super fast, and does reset the root snapshot. This is pretty much what we’re building the feature for!

clone is effectively the same as run, it’s just shorthand. If clone is fast it probably landed on hardware with a cached Docker image. You can’t control that yet, but you’ll be able to hint that you want it to happen someday.

If stop / start is slow, just wait a few weeks. :slight_smile:

1 Like

Great to know. I’ll make some more definitive tests and measure the improvements as they come :slight_smile:

Sorry for not replying sooner - for some reason, I didn’t get any notification about your replies and only seen them now.

My use case is someone similar to @jeffmcaffer’s use case: I want to be able to run workloads on behalf of users inside the VMs, and ideally clear the state of the VM between each run. These workloads usually take between half a second and a minute, and the user is interactively waiting for them to complete, so speed is an important factor.

Right now I’m using DIND (Docker-in-Docker) to start a container inside fly’s Firecracker VM, and then delete the container when the user’s workload is done and create a new container for the next user. The downside is that I have to use an external volume to store the internal docker image, which means scaling becomes more complex.

Another way to go might be limiting the VMs to one user at a time, and then running a script that will clean up the state. However, from my experiments so far it seems like the Fly.io balancer isn’t optimized for this use case - I haven’t found a reliable way to limit the concurrent request amount to one per VM and make sure that a new VM is started in case all the existing ones are currently busy.

p.s. fly is definitely amazing. Thanks for creating it!