novox/mesh-catalog
3
0
Fork 0
Code Issues Pull Requests 1 Packages Projects Releases Wiki Activity

ombi: its config is placed, its image is the one ace runs #145

Closed
mesh-admin wants to merge 1 commits from feat/ombi-for-ace into main
pull from: feat/ombi-for-ace
merge into: :main
Conversation 1 Commits 1 Files Changed 1
+12 -9
mesh-admin commented 2026-09-29 21:39:03 +00:00
Contributor
Copy Link
Copy Source

ombi's definition named /services/ombi/config (a HAL machine path) in three
places and pinned an image older than the one ace runs. Ombi migrates its
own SQLite schema, so a take onto the older pin (v4.53.10-ls267) would start
it on a database the newer build (ls269) already touched.

  • config is a pathless placed directory, mounted as ${dir:config}
  • a state directory placed at the assignment root carries route.json
  • image pinned to the digest ace runs today (v4.53.10-ls269)
  • the sidecar reaches ombi on the machine port the mesh assigns
    (${port:3579}) rather than assuming 3579 is free
  • the sidecar no longer mounts ombi's data directory: MESH_OMBI_CONFIG_DIR
    is read by no code, and the mount exposed the databases for nothing

Verified: catalogue tests (MESH_CATALOGUE set, 6 pass, none skipped); the
pinned image starts as PUID 1000 in a 0700 dir and answers /api/v1/Status
200; data owned 1001:2000 (ace's media ids) under a 1000:1000 dir is
re-owned by the image's init and serves 200; a minted ApiKey is refused
(401) - the api-key secret must be accepted from ombi's own settings.

Open for the operator: ombi reaches sonarr/radarr/lidarr by container name on HAL's proxy network (settings held in its own DB); the catalogue has no contract for one module calling another's HTTP API, so those integrations need re-pointing (e.g. to the arrs' mesh route names) when either side moves. The api-key own-secret cannot be minted usefully on any machine: ombi generates its key itself and no env/file sets it.

ombi's definition named /services/ombi/config (a HAL machine path) in three places and pinned an image older than the one ace runs. Ombi migrates its own SQLite schema, so a take onto the older pin (v4.53.10-ls267) would start it on a database the newer build (ls269) already touched. - config is a pathless placed directory, mounted as ${dir:config} - a state directory placed at the assignment root carries route.json - image pinned to the digest ace runs today (v4.53.10-ls269) - the sidecar reaches ombi on the machine port the mesh assigns (${port:3579}) rather than assuming 3579 is free - the sidecar no longer mounts ombi's data directory: MESH_OMBI_CONFIG_DIR is read by no code, and the mount exposed the databases for nothing Verified: catalogue tests (MESH_CATALOGUE set, 6 pass, none skipped); the pinned image starts as PUID 1000 in a 0700 dir and answers /api/v1/Status 200; data owned 1001:2000 (ace's media ids) under a 1000:1000 dir is re-owned by the image's init and serves 200; a minted ApiKey is refused (401) - the api-key secret must be accepted from ombi's own settings. Open for the operator: ombi reaches sonarr/radarr/lidarr by container name on HAL's `proxy` network (settings held in its own DB); the catalogue has no contract for one module calling another's HTTP API, so those integrations need re-pointing (e.g. to the arrs' mesh route names) when either side moves. The api-key own-secret cannot be minted usefully on any machine: ombi generates its key itself and no env/file sets it.
mesh-admin added 1 commit 2026-09-29 21:39:03 +00:00
ombi: its config is placed, its image is the one ace runs 21f5301268 
ombi's definition named /services/ombi/config (a HAL machine path) in three
places and pinned an image older than the one ace runs. Ombi migrates its
own SQLite schema, so a take onto the older pin (v4.53.10-ls267) would start
it on a database the newer build (ls269) already touched.

- config is a pathless placed directory, mounted as ${dir:config}
- a state directory placed at the assignment root carries route.json
- image pinned to the digest ace runs today (v4.53.10-ls269)
- the sidecar reaches ombi on the machine port the mesh assigns
  (${port:3579}) rather than assuming 3579 is free
- the sidecar no longer mounts ombi's data directory: MESH_OMBI_CONFIG_DIR
  is read by no code, and the mount exposed the databases for nothing

Verified: catalogue tests (MESH_CATALOGUE set, 6 pass, none skipped); the
pinned image starts as PUID 1000 in a 0700 dir and answers /api/v1/Status
200; data owned 1001:2000 (ace's media ids) under a 1000:1000 dir is
re-owned by the image's init and serves 200; a minted ApiKey is refused
(401) - the api-key secret must be accepted from ombi's own settings.
mesh-admin commented 2026-09-30 19:42:58 +00:00
Author
Contributor
Copy Link
Copy Source

Superseded: this module now lives in novox/mesh-media-catalog (the media chain, consolidated from #145–#168 in stack order; its non-media parts merged via #195). Closing.

Superseded: this module now lives in novox/mesh-media-catalog (the media chain, consolidated from #145–#168 in stack order; its non-media parts merged via #195). Closing.
mesh-admin closed this pull request 2026-09-30 19:45:14 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jschoubben miel.truyen
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/mesh-catalog#145