Can’t get volume to attach to multi-process app - “needs volumes” error won’t go away

Questions / Help
,
1

I’m deploying a two-process Fly app:

[[mounts]]
  source      = "earnings_data"
  destination = "/app"
  processes   = ["app"]

[[mounts]]
  source      = "datomic_volume"
  destination = "/app/storage"
  processes   = ["datomic"]

What I did

  1. Created the volumes
  2. fly volumes list now shows both volumes, each in region iad and not attached except earnings_data which is on the app VM
  3. Deployed (fly deploy) and hit this error:
Error: Process group 'datomic' needs volumes with name 'datomic_volume'
to fulfill mounts defined in fly.toml; Run `fly volume create datomic_volume -r REGION -n COUNT`

even though that volume already exists.

Tried re-creating / attaching with no luck.

Question

  • What’s the correct command (or toml syntax) to get datomic_volume attached to the datomic process group’s machine?
  • Is there a hidden step to mark an existing volume as “eligible” for a process-filtered mount?
  • Docs only mention single-volume apps which doesn’t fit this per-process setup.

Any guidance appreciated—thanks!

I see this thread which looks very similar to my issue but was closed with no answer: Process group ‘app’ needs volumes with name...

2

Hm… That thread keeps coming up in searches, etc., even though it’s some of my least effective writing ever on this site, :grimacing:…

Anyway, like in that earlier discussion, there are actually two questions: (a) what this error is really asking you to do and (b) whether the frustration around this is a sign that you have an architecture mismatch to begin with.

Setting (a) aside for the moment, are you sure that you don’t want Datomic as a separate app?

That is the much more usual way of doing databases on the Fly.io platform.

(Process groups are mostly only useful for tightly coupled, Rails-style background workers, in my opinion.)

Aside: Always have a second copy of every volume, unless it’s throwaway data or has streaming backups to Tigris, etc. I.e., for every distinct mounts.source name, there should be ≥2 volumes with that name, clustering with each other at the app level to keep themselves in synch. Otherwise, you risk permanent data loss, :dragon:…

4

I’m not entirely sure there. It’s pretty lightweight accessing sqlite. If that is the common pattern can you point me to doc showing this deployment strategy. If it’s setup within one repo how does that change the setup and organization of the repo given a fly.toml?

5

Sure, Legacy Postgres and Fly.io’s MySQL instructions both work that way.

The database is its own app, with its own Dockerfile, image in the registry, logs, fly.toml, Flycast address, etc.

The Fly.io platform is hard for databases, in general, which is why there isn’t really a lot of tutorial-level material on how to do them here…

That is the “monorepo” style, I think, although perhaps I’m misunderstanding…

https://fly.io/docs/launch/monorepo/

you can also configure flyctl to build and deploy multiple apps from a monorepo or deploy an app to multiple targets.

(Personally, I would just use entirely separate directories.)

1 Like
6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.