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

sonarr, radarr, lidarr provide their API; ombi reaches them through the mesh #156

Open
mesh-admin wants to merge 7 commits from feat/servarr-api-provision into main
pull from: feat/servarr-api-provision
merge into: :main
Conversation 2 Commits 7 Files Changed 17
+1133 -20
mesh-admin commented 2026-09-29 22:40:07 +00:00
Contributor
Copy Link
Copy Source

ombi reaches Sonarr, Radarr and Lidarr through the mesh instead of by container name on HAL's proxy network, which the mesh does not have. Development and tests only — nothing is assigned or deployed.

Includes two unmerged branches

  • origin/feat/ombi-for-ace (PR #145) — ombi's converted manifest. This PR builds on it.
  • origin/fix/sidecars-dial-the-port-they-were-given (PR #154) — the sonarr/radarr/lidarr sidecars dial ${port:…}.

Merge those two first; this diff then shrinks to the two commits below.

The provision: one per app, not one servarr-api

provider provides (scope mesh) serves a consumer's binding
sonarr sonarr-api {scheme: http, port: 8989, url-base: ""} at, port (the machine's published port), scheme, url-base, as, from
radarr radarr-api {scheme: http, port: 7878, url-base: ""} same
lidarr lidarr-api {scheme: http, port: 8686, url-base: ""} same

The pair credential, delivered as the file under secrets.<app>-api, is the app's API key.

Why not one servarr-api with three providers. The controller cannot express one consumer requiring one name from several providers:

  • requires is a list of names, and a requirement is matched by name everywhere. ADR 0094 rejected "require the provision several times" for exactly this reason.
  • A mesh-scoped name with more than one provider is refused unless the node pins one, and Pinned is per node per provision (resolve.go). So one name gets one provider for every consumer on the node.
  • ADR 0094's local names give one consumer several credentials from one provider. They do not give it several providers.

ADR 0027 points the same way. ombi's code is coupled to each app's own API: Sonarr and Radarr speak v3, Lidarr speaks v1, and ombi keeps a different settings document for each. A per-app name is the honest contract.

No grants and no provisioner on the providers. A Servarr instance has exactly one API key, so a per-consumer credential cannot be minted into it.

Rejected alternative: the provider's sidecar writes a minted key into the app. Servarr would take one (<ApiKey> in config.xml, or SONARR__AUTH__APIKEY). But the mesh mints one credential per consumer pair. With two consumers (ombi and, later, jackett or bazarr) there are two different values and only one slot. Writing them would also replace the key every existing client already uses.

ombi: a run-once step that writes into ombi's database through ombi's API

ombi keeps its Servarr connections in OmbiSettings.db, not in a file. The new servarr container is run-once, runs on the host network and runs /app/modules/ombi/dist/servarr/index.js. It follows route-adapter's step pattern. For each app it:

  1. Reads the binding and the pair credential.
  2. Tries the key against the app itself (/api/v3/system/status, or /api/v1/system/status for Lidarr).
  3. Reads ombi's settings (GET /api/v1/Settings/<app>) and compares only ip, port, ssl, subDir and apiKey.
  4. POSTs those fields only when they differ. Quality profiles, root folders, language profiles, tags and enabled are kept as they are. Radarr's settings document is {radarr, radarr4K}; only radarr is touched.
  5. Has ombi test the connection from its own container (POST /api/v1/Tester/<app>).
  • Inputs: ombi's own api-key secret and the six mesh files. restart-on names all six (bound-*, secret-*), so the step runs again when a provider moves or a credential is accepted (ADR 0099).
  • Placement: declared last, so a failure gates nothing else of ombi's (ADR 0136). It exits non-zero on any failure, and the host retries it on the next apply.
  • Refusals:
    • A loopback at (a machine off the private network) is refused: from ombi's container, loopback is ombi itself.
    • A value that is not accepted is never written. See below.

When the pair credential has not been accepted yet

SecretFor mints a random value for any pair that has none (internal/inventory/secrets.go), and no Servarr app will ever accept it. The step finds this in step 2 (a 401), writes nothing, keeps ombi's working key, and fails with:

[ombi-servarr] sonarr: sonarr refuses the sonarr-api credential the mesh delivered, so it was not written into ombi. ... accept sonarr's own key for this pair — `secret accept <this node> ombi sonarr-api --provider ace --from <file holding sonarr's ApiKey>`

Migration on ace (operator steps)

  1. sonarr, radarr and lidarr must be assigned somewhere before ombi can be assigned. With none of them, the resolver refuses: nothing in this mesh provides "sonarr-api", wanted by ombi — assign sonarr to a node.
  2. For each pair, accept the app's own <ApiKey> from its config.xml (/services/<app>/config/config.xml today):
    • secret accept ace ombi sonarr-api --provider ace --from <sonarr ApiKey file>
    • secret accept ace ombi radarr-api --provider ace --from <radarr ApiKey file>
    • secret accept ace ombi lidarr-api --provider ace --from <lidarr ApiKey file>
    • plus ombi's own secret accept ace ombi api-key, as in PR #145.
  3. Any future consumer of the same app accepts the same value for its own pair. Rotating an app's key means accepting the new value for every pair; the mesh cannot rotate an accepted pair.

Tested

  • MESH_CATALOGUE=<this branch> go test -count=1 ./internal/catalogue/ ./internal/inventory/ in mesh-controller passes. The catalogue parse test reports 73 manifests and is not skipped.

  • Resolution scratch tests against this branch's real manifests (not committed to mesh-controller). On one node with sonarr, radarr, lidarr, ombi and route-adapter:

    • Three needs For: ombi.
    • Bindings with at: ace.internal and the machine-side port (20101/20102/20103 given).
    • Sealed secret files at ${dir:state}/<app>-api.secret.
    • The step's restart-on renamed to ombi.bound-* and ombi.secret-*, each naming a resource in the declaration.
    • No unfilled ${…}, and the step ordered after ombi.server and ombi.runtime.

  • Resolution with providers on another node resolves. With none, the refusal names all three. With two sonarrs, it is refused until pinned, and the pin is honoured.

  • npm run typecheck, npm run build (the Dockerfile's tsc line, non-strict) and npm test pass: 9 tests against fake ombi and fake apps.

  • End to end with throwaway containers (catalogue-pinned sonarr, radarr, lidarr and ombi digests, fresh scratch config, private docker network), with ombi preloaded with HAL-style settings (ip: sonarr, qualityProfile: 3, a 4K radarr, …):

    1. Minted credentials: all three refused with the accept remedy, exit 1, ombi byte-for-byte unchanged.
    2. The apps' own keys delivered: wrote ip, apiKey; connection tested for each, exit 0. Only ip and apiKey changed (plus the id ombi assigns on its first save). Radarr 4K was untouched. ombi's Tester returns isValid: true for all three, and ombi lists Sonarr's quality profiles through the new connection.
    3. Rerun: already as the mesh says, no writes, exit 0.

    Everything was removed afterwards.

Open questions / model gaps

  • Accept-only pair credentials. The mesh cannot mark a provision "accept, never mint". An unaccepted pair gets a random value, and only the consumer's own check makes that visible. Proposed hq issue: a provider declares a provision's credential accepted-only; the plan refuses the pair until it is accepted, and secret accept for such a pair can be given once per provider and fanned out to its consumer pairs.
  • One value accepted N times. Every consumer of one app needs the same key accepted separately. The per-provider accept above would fix this too.
  • Optional requirements. ombi cannot be assigned until all three apps are. A mesh without Lidarr cannot run ombi. Proposed hq issue: an optional requirement, bound when answered and absent otherwise.
  • Provider-side verification. With grants, the provider's sidecar (which already reads config.xml) could check each consumer's delivered pair credential against the app's real key and report a mismatch on the provider too. Not built.
  • Serves settled from all of the provider's settings. servedOnThisMachine lays the provider module's whole settings layer over serves. A url-base setting on sonarr reaches consumers, which is intended, but so would any other setting key. Worth a look in the controller.
  • Same shape next, not built here: sonarr and radarr → jackett (jackett-torznab, where jackett has one API key, so the same accepted pattern applies) and bazarr / home-assistant → sonarr-api / radarr-api consumers with their own write-in steps.
ombi reaches Sonarr, Radarr and Lidarr through the mesh instead of by container name on HAL's `proxy` network, which the mesh does not have. **Development and tests only — nothing is assigned or deployed.** ## Includes two unmerged branches - `origin/feat/ombi-for-ace` (**PR #145**) — ombi's converted manifest. This PR builds on it. - `origin/fix/sidecars-dial-the-port-they-were-given` (**PR #154**) — the sonarr/radarr/lidarr sidecars dial `${port:…}`. Merge those two first; this diff then shrinks to the two commits below. ## The provision: one per app, not one `servarr-api` | provider | provides (scope mesh) | serves | a consumer's binding | |---|---|---|---| | sonarr | `sonarr-api` | `{scheme: http, port: 8989, url-base: ""}` | `at`, `port` (the machine's published port), `scheme`, `url-base`, `as`, `from` | | radarr | `radarr-api` | `{scheme: http, port: 7878, url-base: ""}` | same | | lidarr | `lidarr-api` | `{scheme: http, port: 8686, url-base: ""}` | same | The pair credential, delivered as the file under `secrets.<app>-api`, is the app's API key. **Why not one `servarr-api` with three providers.** The controller cannot express one consumer requiring one name from several providers: - `requires` is a list of names, and a requirement is matched by name everywhere. ADR 0094 rejected "require the provision several times" for exactly this reason. - A mesh-scoped name with more than one provider is refused unless the node pins one, and `Pinned` is per node per provision (`resolve.go`). So one name gets one provider for every consumer on the node. - ADR 0094's local names give one consumer several credentials **from one provider**. They do not give it several providers. ADR 0027 points the same way. ombi's code is coupled to each app's own API: Sonarr and Radarr speak v3, Lidarr speaks v1, and ombi keeps a different settings document for each. A per-app name is the honest contract. **No `grants` and no provisioner on the providers.** A Servarr instance has exactly one API key, so a per-consumer credential cannot be minted into it. **Rejected alternative: the provider's sidecar writes a minted key into the app.** Servarr would take one (`<ApiKey>` in config.xml, or `SONARR__AUTH__APIKEY`). But the mesh mints one credential per consumer pair. With two consumers (ombi and, later, jackett or bazarr) there are two different values and only one slot. Writing them would also replace the key every existing client already uses. ## ombi: a run-once step that writes into ombi's database through ombi's API ombi keeps its Servarr connections in `OmbiSettings.db`, not in a file. The new `servarr` container is `run-once`, runs on the host network and runs `/app/modules/ombi/dist/servarr/index.js`. It follows route-adapter's step pattern. For each app it: 1. Reads the binding and the pair credential. 2. Tries the key against the app itself (`/api/v3/system/status`, or `/api/v1/system/status` for Lidarr). 3. Reads ombi's settings (`GET /api/v1/Settings/<app>`) and compares **only** `ip`, `port`, `ssl`, `subDir` and `apiKey`. 4. `POST`s those fields only when they differ. Quality profiles, root folders, language profiles, tags and `enabled` are kept as they are. Radarr's settings document is `{radarr, radarr4K}`; only `radarr` is touched. 5. Has ombi test the connection from its own container (`POST /api/v1/Tester/<app>`). - **Inputs:** ombi's own `api-key` secret and the six mesh files. `restart-on` names all six (`bound-*`, `secret-*`), so the step runs again when a provider moves or a credential is accepted (ADR 0099). - **Placement:** declared last, so a failure gates nothing else of ombi's (ADR 0136). It exits non-zero on any failure, and the host retries it on the next apply. - **Refusals:** - A loopback `at` (a machine off the private network) is refused: from ombi's container, loopback is ombi itself. - A value that is not accepted is never written. See below. ### When the pair credential has not been accepted yet `SecretFor` mints a random value for any pair that has none (`internal/inventory/secrets.go`), and no Servarr app will ever accept it. The step finds this in step 2 (a 401), writes nothing, keeps ombi's working key, and fails with: ``` [ombi-servarr] sonarr: sonarr refuses the sonarr-api credential the mesh delivered, so it was not written into ombi. ... accept sonarr's own key for this pair — `secret accept <this node> ombi sonarr-api --provider ace --from <file holding sonarr's ApiKey>` ``` ## Migration on ace (operator steps) 1. `sonarr`, `radarr` and `lidarr` must be assigned somewhere before ombi can be assigned. With none of them, the resolver refuses: `nothing in this mesh provides "sonarr-api", wanted by ombi — assign sonarr to a node`. 2. For each pair, accept the app's own `<ApiKey>` from its config.xml (`/services/<app>/config/config.xml` today): - `secret accept ace ombi sonarr-api --provider ace --from <sonarr ApiKey file>` - `secret accept ace ombi radarr-api --provider ace --from <radarr ApiKey file>` - `secret accept ace ombi lidarr-api --provider ace --from <lidarr ApiKey file>` - plus ombi's own `secret accept ace ombi api-key`, as in PR #145. 3. Any future consumer of the same app accepts **the same value** for its own pair. Rotating an app's key means accepting the new value for every pair; the mesh cannot rotate an accepted pair. ## Tested - `MESH_CATALOGUE=<this branch> go test -count=1 ./internal/catalogue/ ./internal/inventory/` in mesh-controller passes. The catalogue parse test reports 73 manifests and is not skipped. - Resolution scratch tests against this branch's real manifests (not committed to mesh-controller). On one node with sonarr, radarr, lidarr, ombi and route-adapter: - Three needs `For: ombi`. - Bindings with `at: ace.internal` and the machine-side port (20101/20102/20103 given). - Sealed secret files at `${dir:state}/<app>-api.secret`. - The step's `restart-on` renamed to `ombi.bound-*` and `ombi.secret-*`, each naming a resource in the declaration. - No unfilled `${…}`, and the step ordered after `ombi.server` and `ombi.runtime`. - Resolution with providers on another node resolves. With none, the refusal names all three. With two sonarrs, it is refused until pinned, and the pin is honoured. - `npm run typecheck`, `npm run build` (the Dockerfile's tsc line, non-strict) and `npm test` pass: 9 tests against fake ombi and fake apps. - End to end with throwaway containers (catalogue-pinned sonarr, radarr, lidarr and ombi digests, fresh scratch config, private docker network), with ombi preloaded with HAL-style settings (`ip: sonarr`, `qualityProfile: 3`, a 4K radarr, …): 1. Minted credentials: all three refused with the accept remedy, exit 1, ombi byte-for-byte unchanged. 2. The apps' own keys delivered: `wrote ip, apiKey; connection tested` for each, exit 0. Only `ip` and `apiKey` changed (plus the `id` ombi assigns on its first save). Radarr 4K was untouched. ombi's Tester returns `isValid: true` for all three, and ombi lists Sonarr's quality profiles through the new connection. 3. Rerun: `already as the mesh says`, no writes, exit 0. Everything was removed afterwards. ## Open questions / model gaps - **Accept-only pair credentials.** The mesh cannot mark a provision "accept, never mint". An unaccepted pair gets a random value, and only the consumer's own check makes that visible. Proposed hq issue: a provider declares a provision's credential `accepted-only`; the plan refuses the pair until it is accepted, and `secret accept` for such a pair can be given once per provider and fanned out to its consumer pairs. - **One value accepted N times.** Every consumer of one app needs the same key accepted separately. The per-provider accept above would fix this too. - **Optional requirements.** ombi cannot be assigned until all three apps are. A mesh without Lidarr cannot run ombi. Proposed hq issue: an optional requirement, bound when answered and absent otherwise. - **Provider-side verification.** With `grants`, the provider's sidecar (which already reads config.xml) could check each consumer's delivered pair credential against the app's real key and report a mismatch on the provider too. Not built. - **Serves settled from all of the provider's settings.** `servedOnThisMachine` lays the provider module's whole settings layer over `serves`. A `url-base` setting on sonarr reaches consumers, which is intended, but so would any other setting key. Worth a look in the controller. - **Same shape next, not built here:** sonarr and radarr → jackett (`jackett-torznab`, where jackett has one API key, so the same accepted pattern applies) and bazarr / home-assistant → `sonarr-api` / `radarr-api` consumers with their own write-in steps.
mesh-admin added 5 commits 2026-09-29 22:40:07 +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.
Sidecars dial the port they were given, not the software's 5cc6258326 
A host-network sidecar reaches its service over the machine's loopback, and
the mesh publishes that service on a machine port it assigns (ADR 0038) —
so dialling the software's port reaches whatever else holds it. On ace,
searxng's sidecar dialled 127.0.0.1:8080 and got unifi's inform port. The
same shape in bazarr, bookshelf, lidarr, nzbget, qbittorrent, radarr and
sonarr; each now asks with ${port:N} (hq 088). Found in review of ace's
module preparation.
Merge remote-tracking branch 'origin/fix/sidecars-dial-the-port-they-were-given' into feat/servarr-api-provision c4c44efb1b
sonarr, radarr, lidarr: provide their API to the mesh ab44ff02e1 
A consumer on another machine (ombi first; jackett, bazarr and home-assistant
later) reached these by container name on HAL's shared network, which the mesh
does not have. Each app now provides <app>-api at mesh scope and serves the
software port, so the mesh tells a consumer where it is and redirects the
port to where the machine published it.

Named per app, not one servarr-api: a requirement is matched by name and
answered by exactly one provider per node, so a consumer cannot require one
name from three providers - and ombi's code is written against each app's
own API version (ADR 0027).

No grants and no provisioner: a Servarr instance has one API key, which the
mesh cannot mint. The operator accepts it as the pair credential for each
consumer (ADR 0092).
ombi: reach sonarr, radarr and lidarr through the mesh f14c763463 
ombi keeps its Servarr connections in its own database, so the mesh has no
file to write them into. A run-once step reads the three bindings and pair
credentials and writes host, port, TLS, base path and key into ombi through
ombi's own API - only when they differ, and nothing else ombi keeps.

Until the operator accepts an app's key for this pair the mesh delivers a
value it minted, which no Servarr app accepts. The step tries the key against
the app first and, refused, writes nothing and fails naming the secret accept
that fixes it, so the old working key in ombi is never replaced by a dead one.

Declared last so its failing gates nothing else of ombi (ADR 0136), and
restart-on its six inputs so it runs again when a provider moves (ADR 0099).
mesh-admin commented 2026-09-29 22:41:33 +00:00
Author
Contributor
Copy Link
Copy Source

Review — approve

  • Per-app provisions (sonarr-api, radarr-api, lidarr-api) are forced by one-provider-per-name-per-node resolution; ADR 0027 agrees (v3 vs v1 APIs, separate ombi settings documents).
  • Accepting each app's existing key per pair is the only design that fits one key slot per Servarr app; the ombi step refusing a minted key with the exact secret accept command — writing nothing, keeping ombi's working key — is the right failure.
  • Writes only host/port/ssl/subDir/apiKey, only when different; 4K untouched; idempotent rerun verified.
  • Checked independently on ace: a bridge container reaches ace.internal:<machine port> while ace is adopted (traefik → searxng does, 200).

Merge order: #145 and #154 first. The proposed follow-ups (accept-only pair credentials, one accept fanning out to all pairs, optional requirements) are worth hq issues.

## Review — approve - Per-app provisions (`sonarr-api`, `radarr-api`, `lidarr-api`) are forced by one-provider-per-name-per-node resolution; ADR 0027 agrees (v3 vs v1 APIs, separate ombi settings documents). - Accepting each app's existing key per pair is the only design that fits one key slot per Servarr app; the ombi step refusing a minted key with the exact `secret accept` command — writing nothing, keeping ombi's working key — is the right failure. - Writes only host/port/ssl/subDir/apiKey, only when different; 4K untouched; idempotent rerun verified. - Checked independently on ace: a bridge container reaches `ace.internal:<machine port>` while ace is adopted (traefik → searxng does, 200). Merge order: #145 and #154 first. The proposed follow-ups (accept-only pair credentials, one accept fanning out to all pairs, optional requirements) are worth hq issues.
jschoubben added 2 commits 2026-09-30 11:14:29 +00:00
ombi: reach plex through the mesh, in the same step as the Servarr apps b068a9d399 
ombi reached plex at its public name, typed into its settings screen, so it
depended on plex's public route and on nobody moving plex. ombi now requires
plex-api, and the run-once step that writes its Servarr connections writes
its Plex one too - renamed from `servarr` to `connections`, since it is no
longer only that.

ombi keeps several Plex servers. The entry this provision names is found by
the server's own machineIdentifier (plex answers it at /identity, and ombi
stored it when the server was loaded), and only its host, port, TLS, base
path and token are written, only when they differ. Another server's entry,
the selected libraries, whether Plex is enabled and every other choice are
left alone. An ombi with no entry for the server gets one.

The token is tried against plex first. Until the operator accepts the
server's X-Plex-Token for this pair the mesh delivers a value it minted,
which plex refuses (401, or 400 on a network it trusts); refused, nothing is
written and the step fails naming the secret accept, so a working token in
ombi is never replaced by a dead one.

Tests import the compiled step, as keycloak's do: the step imports its
sibling with the .js specifier the build needs, which type stripping does
not resolve. `npm test` builds first.
ombi: adopt the Plex entry that plex itself answers for 0010b6bf21 
ace's ombi holds one Plex entry, loaded from an older server and later
retyped to plex's public name: its stored machineIdentifier is not plex's,
while its address answers as plex. Matching by identifier alone would leave
it and add a second entry for the same server.

When no entry carries the server's identifier, each entry's own address is
asked for /identity, and an entry plex answers for is adopted: the bound
connection laid over, and the identifier corrected (ombi builds its "view in
Plex" links from it). Its name, libraries and every other choice stay. An
entry that cannot be asked, or answers as another server, is left alone;
nothing is guessed. Every call of the step is now bounded, since an entry may
name a host that no longer answers.
mesh-admin commented 2026-09-30 11:15:07 +00:00
Author
Contributor
Copy Link
Copy Source

ombi now reaches plex through plex-api, in the same step as the Servarr apps (commits b068a9d, 0010b6b)

  • The step is renamed from servarr to connections (mesh-ombi-connections, connections/index.ts), because it now covers plex too. servarr/settings.ts is unchanged apart from exporting ombiCall and isLoopback. Every HTTP call is now bounded to 20 s.
  • plex/settings.ts:
    • It checks the token against plex before writing anything. On a refusal it writes nothing and names secret accept ace ombi plex-api --provider ace --from <file>.
    • It finds this server's entry by the machineIdentifier plex answers at /identity, and writes only ip, port, ssl, subDir and plexAuthToken, only when they differ.
    • Libraries, enable, watchlist import and batch size are never touched, and neither is any other server's entry.
    • If ombi has no entry for this server, one is added.
    • It finishes with ombi's own POST /Tester/plex.
  • Adoption, needed on ace. A read-only look at ace's OmbiSettings.db (secret fields filtered out) shows one entry, "Nami". Its identifier is stale (7656…, from an older server), while its address, plex.zurag.be:443, answers as today's plex (a728…). When no entry carries the identifier, the step asks each entry's own address for /identity. An entry plex answers for is adopted: it gets the bound connection plus the corrected identifier, and keeps its name and its 6 libraries. Entries that are unreachable or answer as another server are left alone.
  • Checks run:
    • Tests: 21 pass (12 plex, 9 servarr). Typecheck and the Dockerfile build pass. go test ./internal/catalogue/ passes.
    • End to end, with a throwaway ombi (4.53.10) and a throwaway Plex:
      1. Minted value: refused, and ombi was left untouched.
      2. Accepted token: the entry was added, and ombi's own Tester returned true.
      3. Rerun: "already as the mesh says".
      4. An operator-edited entry (public name, 443, ssl): the step wrote ip, port and ssl, and kept enable and the batch size.
      5. A stale-identifier entry: adopted, with port and machineIdentifier written.
**ombi now reaches plex through `plex-api`, in the same step as the Servarr apps** (commits b068a9d, 0010b6b) - **The step is renamed** from `servarr` to `connections` (`mesh-ombi-connections`, `connections/index.ts`), because it now covers plex too. `servarr/settings.ts` is unchanged apart from exporting `ombiCall` and `isLoopback`. Every HTTP call is now bounded to 20 s. - **`plex/settings.ts`:** - It checks the token against plex before writing anything. On a refusal it writes nothing and names `secret accept ace ombi plex-api --provider ace --from <file>`. - It finds this server's entry by the machineIdentifier plex answers at `/identity`, and writes only ip, port, ssl, subDir and plexAuthToken, only when they differ. - Libraries, `enable`, watchlist import and batch size are never touched, and neither is any other server's entry. - If ombi has no entry for this server, one is added. - It finishes with ombi's own `POST /Tester/plex`. - **Adoption, needed on ace.** A read-only look at ace's OmbiSettings.db (secret fields filtered out) shows one entry, "Nami". Its identifier is stale (`7656…`, from an older server), while its address, `plex.zurag.be:443`, answers as today's plex (`a728…`). When no entry carries the identifier, the step asks each entry's own address for `/identity`. An entry plex answers for is adopted: it gets the bound connection plus the corrected identifier, and keeps its name and its 6 libraries. Entries that are unreachable or answer as another server are left alone. - **Checks run:** - **Tests:** 21 pass (12 plex, 9 servarr). Typecheck and the Dockerfile build pass. `go test ./internal/catalogue/` passes. - **End to end,** with a throwaway ombi (4.53.10) and a throwaway Plex: 1. Minted value: refused, and ombi was left untouched. 2. Accepted token: the entry was added, and ombi's own Tester returned true. 3. Rerun: "already as the mesh says". 4. An operator-edited entry (public name, 443, ssl): the step wrote ip, port and ssl, and kept `enable` and the batch size. 5. A stale-identifier entry: adopted, with port and machineIdentifier written.
You are not authorized to merge this pull request.
This pull request can be merged automatically.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin feat/servarr-api-provision:feat/servarr-api-provision
git checkout feat/servarr-api-provision
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
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/mesh-catalog#156