freesailarr: MediathekArr als zehnten Container aufnehmen #20

Closed
opened 2026-09-16 16:03:33 +02:00 by jlab-bot · 1 comment
Member

Migriert aus jk-cluster/helm-charts#245 — urspruenglich angelegt von jk-cluster-bot am 2026-09-08.

Verweise der Form #123 im folgenden Text beziehen sich auf die GitHub-Nummerierung, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar.


MediathekArr (https://github.com/PCJones/MediathekArr) soll als zehnter Container in den freesailarr-Pod. Es täuscht gegenüber Prowlarr einen Usenet-Indexer und gegenüber Sonarr/Radarr einen SABnzbd-Downloader vor und lädt Inhalte per HTTP direkt aus den Mediatheken von ARD und ZDF.

Beide Abnehmer sitzen bereits im Pod und teilen sich gluetuns Netzwerk-Namensraum — sie erreichen MediathekArr über 127.0.0.1, ohne Service, ohne DNS, ohne Ingress-Umweg. Der Zuschnitt passt also, und die Aufnahme ist rein additiv.

Alles Folgende ist gemessen, in zwei Runden in Wegwerf-k3d-Clustern, jeweils mit Kontrolllauf über direkten Egress. Wo etwas nicht gemessen ist, steht es ausdrücklich dabei.

Der Geo-Vorbehalt, und warum er den Chart nicht aufhält

Der Tunnel geht per Chart-Vorgabe über Zürich; ARD und ZDF sperren Teile ihres Katalogs außerhalb Deutschlands. Alle Container hängen an gluetuns Namensraum, einen Bypass für einen einzelnen Container gibt es nicht.

Streuprobe, 480 URLs über 12 Kanäle: 104 von 473 direkt ladbaren URLs sind über Zürich gesperrt = 22,0 % (KI etwa 18–26 %). Auf der deutschen Seite kein einziger Fehlschlag. Die Verteilung ist stark ungleich: ONE 97,5 %, ZDFneo 47,5 %, ZDFinfo 37,5 %, Das Erste 20,5 %, ZDF 10,3 %, BR 0 %.

Vollerhebung über sechs konkret nachgefragte Formate, 584 URLs, keine Stichprobe: vier Serien zu 100 % ladbar, eine praktisch (nur ein Trailer gesperrt), eine zu 95 % gesperrt.

Die Ausgangswahl ist ein Deployment-Wert, keine Chart-Eigenschaft. Der Chart entsteht unabhängig davon; er schuldet nur eine ehrliche Dokumentation.

Was dokumentiert wird: das Verfahren, nicht die Momentaufnahme

Der Geo-Marker im CDN-Pfad war über beide Runden hinweg ein perfekter Prädiktor — in der Vollerhebung 584 von 584 Fällen korrekt, keine einzige Fehlklassifikation:

Marker im Pfad Verhalten außerhalb DE
/de/, /geo/de/, /deutschlandweit/, geoavailability_D gesperrt
/weltweit/ offen
/none/ (ZDF) offen
/dach/, deChAt (WDR-Variante) offen — die Schweiz liegt in DACH

Eine Serientabelle in values.yaml wäre in einem halben Jahr veraltet. Das Verfahren nicht: wer wissen will, ob seine Sendung über einen fremden Ausgang funktioniert, sieht im Pfad der Medien-URL nach. Das gehört in die Dokumentation, zusammen mit dem Fluchtweg (deutscher Ausgang für den gesamten Stack) und dessen Preis.

Die naheliegende Faustregel „Eigenproduktion = weltweit frei" ist belegt falsch und darf so nicht in der Dokumentation landen: eine ARD-Eigenproduktion war gesperrt, eine Lizenzserie offen. Nur der Marker zählt.

Die Falle, die in NOTES.txt gehört

MediathekArr prüft den HTTP-Statuscode nie. A/B gemessen mit identischem NZB:

direkt (DE) über Zürich
status Completed Failed
bytes 94 235 525 0
fail_message null null

Bei gesperrtem Abruf schreibt es die rund 476 Byte große HTML-Fehlerseite als .mp4 weg und protokolliert „Download completed". Erst mkvmerge verweigert die Datei (Exit-Code 2) und kippt den Status auf Failed.

Zwei Konsequenzen, beide dokumentationspflichtig:

  1. Sonarr bekommt „fehlgeschlagen" ohne Grund. fail_message ist null. Eine Geosperre sieht im Betrieb exakt aus wie ein defekter Server, eine abgelaufene URL oder ein voller Datenträger. Auch der Containerlog nennt die 403 nicht.
  2. Der Schutz ist ein Zufallsprodukt, kein Fehlerhandling. Er hängt allein daran, dass mkvmerge die HTML-Seite ablehnt. Jede Geo-Antwort, die mkvmerge akzeptiert, würde als Completed gemeldet — und dann wandern kaputte Dateien in die Bibliothek. In beiden Messrunden ist das nicht eingetreten (Akamai liefert durchgehend HTML), aber darauf ist kein Verlass.

Umsetzung — was gemessen ist

Zwei Ports, nicht einer. MediathekArrDownloader (SABnzbd-Rolle) auf 5007, MediathekArrServer (Newznab-Rolle für Prowlarr) auf 5008. Die Upstream-Dokumentation nennt nur 5007. Im Pod sind belegt: 9999, 8080, 9696, 8191, 7878, 8989, 5055, 6767 — beide neuen Ports sind frei.

Die SABnzbd-API liegt unter /download/api, nicht unter /api. /api auf 5007 antwortet mit einem Newznab-Validierungsfehler und führt in die Irre.

Startgate auf gluetun — der schärfste Punkt. Startet MediathekArr, bevor der Tunnel steht, scheitert der Ruleset-Abruf, und die Instanz lieferte danach über elf Minuten hinweg 0 Treffer auf jede Newznab-Suche, ohne dass ein Retry das reparierte. Mit 75 s Verzögerung: Ruleset ok, Suche identisch zur direkten Instanz. Ohne Startgate ist der Indexer stumm und nichts meldet es — kein Fehler, keine unready Probe, nur leere Suchergebnisse. Die Suche selbst ist nicht geogesperrt (56 Treffer über beide Ausgänge).

Härtung, drei Varianten gemessen. Der auskommentierte Nicht-Root-Block im Dockerfile ist für den beta-Stand überholt (docker_start.sh enthält einen gosu-Pfad). Ergebnis:

  • runAsNonRoot: true + runAsUser: 1000 + readOnlyRootFilesystem: true + fsGroup: 1000 läuft vollständig durch, inklusive echtem Download und mkvmerge-Remux.
  • Ohne beschreibbare Volumes stürzt der Container ab.
  • PUID/PGID wird dabei nicht gebraucht.

Beschreibbar sein müssen:

  • /app/config — Konfigurations-JSON, gehört auf einen eigenen volumeClaimTemplate wie bei den anderen Apps.
  • /data/mediathek — incomplete/ und complete/.
  • /tmp war nicht erforderlich (die RO-Variante ohne /tmp lief durch). Als billige Absicherung trotzdem sinnvoll — das ist eine Empfehlung, keine Messung.

/app/downloads wird von der Anwendung gar nicht benutzt, obwohl die docker-compose.yml es als Volume führt. Ihre Vorgaben sind /data/mediathek/incomplete und /data/mediathek/complete.

Wohin die Downloads gehören — zu entscheiden, nicht zu raten. complete/ muss auf dem geteilten downloads-Claim liegen, sonst kann Sonarr im selben Pod nichts importieren, und DOWNLOAD_FOLDER_PATH_MAPPING muss auf genau diesen Pfad zeigen — eine Abweichung importiert schweigend nichts. incomplete/ gehört nicht in einen emptyDir: ein emptyDir zählt gegen das ephemeral-storage-Limit des Containers, und ein großer Download lässt den kubelet den ganzen Pod räumen, mit allen neun anderen Containern. Das ist dieselbe Falle, die in ytdlp-web-player dokumentiert ist.

Image per Digest pinnen. Die Tags sind unbrauchbar: latest stammt vom 12.11.2024 (= v0.2.5), die README empfiehlt beta (zuletzt 15.06.2026). Aufgelöst:

pcjones/mediathekarr:beta
sha256:3ed7e1487810e1519301bd56a0c420e260e428295b029a47806c0397e4a52a33

Single-Arch, nur linux/amd64, kein arm64 — gehört als Kommentar an die Stelle, auch wenn der Zielcluster durchgehend amd64 ist. Dazu eine Renovate-Regel für Digest-Updates, im Trockenlauf belegt: eine gültige Regel ist keine treffende Regel (#158, searxng-Runde).

Es gibt keinen Health-Endpunkt. Gemessen 404 auf /health, /healthz, /api/health, /download/health, /status, /ping. Belegte 200er-Kandidaten für die Probes:

  • Port 5008: GET /api?t=caps
  • Port 5007: GET /download/api?mode=version&output=json&apikey=x oder GET /download/

Offen, ausdrücklich ungemessen

Ein Teil des Mediathek-Bestands liegt als HLS-Playlist (application/x-mpegURL) statt als progressives MP4 vor. MediathekArrs Downloader lädt eine einzelne HTTP-Datei und remuxt sie mit mkvmerge; ob er mit einer m3u8-Playlist umgehen kann, ist nicht gemessen. Falls nicht, fallen diese Einträge unabhängig von jeder Geosperre aus. Das gehört als offene Frage in values.yaml, nicht als Annahme in die eine oder andere Richtung.

Zu belegen

  1. Der Chart rendert und installiert, mit mediathekarr.enabled: true und false, ohne dass bestehende Installationen sich ändern.
  2. Das Startgate wirkt. Zeigen, dass der Container nicht vor gluetuns Bereitschaft startet — und dass die Newznab-Suche danach Treffer liefert. Ein grüner Pod ist hier kein Beleg, weil der Fehlerfall grün aussieht.
  3. Die Probes. Auf einem der belegten 200er-Pfade, nicht auf einem geratenen.
  4. Die Renovate-Digest-Regel im Trockenlauf.
  5. Härtung wie gemessen: nicht-root, uid 1000, readOnlyRootFilesystem: true.

Versionsstufe

Minor — rein additiv, standardmäßig aus, und der volumeClaimTemplate entsteht nur bei aktiviertem Flag, sodass sich für bestehende Installationen nichts ändert. Aktuell 3.0.5+up1.0.0, also 3.1.0+up1.0.0. Die appVersion des Charts bleibt unberührt: sie ist frei gewählt und an kein Upstream gebunden, alle Images sind in values.yaml gepinnt.

Dazu wie üblich: values.schema.json, CI-Fixtures unter ci/freesailarr/, Renovate-Eintrag, README-Aktualisierung, wo sie repo-weites Verhalten berührt.

> Migriert aus [`jk-cluster/helm-charts#245`](https://github.com/jk-cluster/helm-charts/issues/245) — urspruenglich angelegt von **jk-cluster-bot** am 2026-09-08. > > Verweise der Form `#123` im folgenden Text beziehen sich auf die **GitHub-Nummerierung**, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar. --- MediathekArr (https://github.com/PCJones/MediathekArr) soll als **zehnter Container** in den freesailarr-Pod. Es täuscht gegenüber Prowlarr einen Usenet-Indexer und gegenüber Sonarr/Radarr einen SABnzbd-Downloader vor und lädt Inhalte per HTTP direkt aus den Mediatheken von ARD und ZDF. Beide Abnehmer sitzen bereits im Pod und teilen sich gluetuns Netzwerk-Namensraum — sie erreichen MediathekArr über `127.0.0.1`, ohne Service, ohne DNS, ohne Ingress-Umweg. Der Zuschnitt passt also, und die Aufnahme ist rein additiv. Alles Folgende ist **gemessen**, in zwei Runden in Wegwerf-k3d-Clustern, jeweils mit Kontrolllauf über direkten Egress. Wo etwas nicht gemessen ist, steht es ausdrücklich dabei. ## Der Geo-Vorbehalt, und warum er den Chart nicht aufhält Der Tunnel geht per Chart-Vorgabe über Zürich; ARD und ZDF sperren Teile ihres Katalogs außerhalb Deutschlands. Alle Container hängen an gluetuns Namensraum, einen Bypass für einen einzelnen Container gibt es nicht. **Streuprobe, 480 URLs über 12 Kanäle:** 104 von 473 direkt ladbaren URLs sind über Zürich gesperrt = **22,0 %** (KI etwa 18–26 %). Auf der deutschen Seite kein einziger Fehlschlag. Die Verteilung ist stark ungleich: ONE 97,5 %, ZDFneo 47,5 %, ZDFinfo 37,5 %, Das Erste 20,5 %, ZDF 10,3 %, BR 0 %. **Vollerhebung über sechs konkret nachgefragte Formate, 584 URLs, keine Stichprobe:** vier Serien zu 100 % ladbar, eine praktisch (nur ein Trailer gesperrt), eine zu 95 % gesperrt. Die Ausgangswahl ist ein **Deployment-Wert, keine Chart-Eigenschaft**. Der Chart entsteht unabhängig davon; er schuldet nur eine ehrliche Dokumentation. ### Was dokumentiert wird: das Verfahren, nicht die Momentaufnahme Der Geo-Marker im CDN-Pfad war über beide Runden hinweg ein **perfekter Prädiktor** — in der Vollerhebung 584 von 584 Fällen korrekt, keine einzige Fehlklassifikation: | Marker im Pfad | Verhalten außerhalb DE | |---|---| | `/de/`, `/geo/de/`, `/deutschlandweit/`, `geoavailability_D` | gesperrt | | `/weltweit/` | offen | | `/none/` (ZDF) | offen | | `/dach/`, `deChAt` (WDR-Variante) | offen — die Schweiz liegt in DACH | Eine Serientabelle in `values.yaml` wäre in einem halben Jahr veraltet. Das Verfahren nicht: wer wissen will, ob seine Sendung über einen fremden Ausgang funktioniert, sieht im Pfad der Medien-URL nach. **Das** gehört in die Dokumentation, zusammen mit dem Fluchtweg (deutscher Ausgang für den gesamten Stack) und dessen Preis. Die naheliegende Faustregel „Eigenproduktion = weltweit frei" ist **belegt falsch** und darf so nicht in der Dokumentation landen: eine ARD-Eigenproduktion war gesperrt, eine Lizenzserie offen. Nur der Marker zählt. ## Die Falle, die in NOTES.txt gehört MediathekArr **prüft den HTTP-Statuscode nie**. A/B gemessen mit identischem NZB: | | direkt (DE) | über Zürich | |---|---|---| | `status` | `Completed` | `Failed` | | `bytes` | 94 235 525 | 0 | | `fail_message` | `null` | **`null`** | Bei gesperrtem Abruf schreibt es die rund 476 Byte große HTML-Fehlerseite als `.mp4` weg und protokolliert „Download completed". Erst **mkvmerge** verweigert die Datei (Exit-Code 2) und kippt den Status auf `Failed`. Zwei Konsequenzen, beide dokumentationspflichtig: 1. **Sonarr bekommt „fehlgeschlagen" ohne Grund.** `fail_message` ist `null`. Eine Geosperre sieht im Betrieb exakt aus wie ein defekter Server, eine abgelaufene URL oder ein voller Datenträger. Auch der Containerlog nennt die 403 nicht. 2. **Der Schutz ist ein Zufallsprodukt, kein Fehlerhandling.** Er hängt allein daran, dass mkvmerge die HTML-Seite ablehnt. Jede Geo-Antwort, die mkvmerge akzeptiert, würde als `Completed` gemeldet — und dann wandern kaputte Dateien in die Bibliothek. In beiden Messrunden ist das nicht eingetreten (Akamai liefert durchgehend HTML), aber darauf ist kein Verlass. ## Umsetzung — was gemessen ist **Zwei Ports, nicht einer.** `MediathekArrDownloader` (SABnzbd-Rolle) auf **5007**, `MediathekArrServer` (Newznab-Rolle für Prowlarr) auf **5008**. Die Upstream-Dokumentation nennt nur 5007. Im Pod sind belegt: 9999, 8080, 9696, 8191, 7878, 8989, 5055, 6767 — beide neuen Ports sind frei. **Die SABnzbd-API liegt unter `/download/api`, nicht unter `/api`.** `/api` auf 5007 antwortet mit einem Newznab-Validierungsfehler und führt in die Irre. **Startgate auf gluetun — der schärfste Punkt.** Startet MediathekArr, bevor der Tunnel steht, scheitert der Ruleset-Abruf, und die Instanz lieferte danach **über elf Minuten hinweg 0 Treffer** auf jede Newznab-Suche, ohne dass ein Retry das reparierte. Mit 75 s Verzögerung: Ruleset ok, Suche identisch zur direkten Instanz. Ohne Startgate ist der Indexer stumm und **nichts meldet es** — kein Fehler, keine unready Probe, nur leere Suchergebnisse. Die Suche selbst ist nicht geogesperrt (56 Treffer über beide Ausgänge). **Härtung, drei Varianten gemessen.** Der auskommentierte Nicht-Root-Block im Dockerfile ist für den `beta`-Stand überholt (`docker_start.sh` enthält einen gosu-Pfad). Ergebnis: - `runAsNonRoot: true` + `runAsUser: 1000` + **`readOnlyRootFilesystem: true`** + `fsGroup: 1000` läuft vollständig durch, inklusive echtem Download und mkvmerge-Remux. - Ohne beschreibbare Volumes stürzt der Container ab. - PUID/PGID wird dabei **nicht** gebraucht. Beschreibbar sein müssen: - `/app/config` — Konfigurations-JSON, gehört auf einen eigenen `volumeClaimTemplate` wie bei den anderen Apps. - `/data/mediathek` — `incomplete/` und `complete/`. - `/tmp` war **nicht** erforderlich (die RO-Variante ohne `/tmp` lief durch). Als billige Absicherung trotzdem sinnvoll — das ist eine Empfehlung, keine Messung. **`/app/downloads` wird von der Anwendung gar nicht benutzt**, obwohl die docker-compose.yml es als Volume führt. Ihre Vorgaben sind `/data/mediathek/incomplete` und `/data/mediathek/complete`. **Wohin die Downloads gehören — zu entscheiden, nicht zu raten.** `complete/` muss auf dem geteilten downloads-Claim liegen, sonst kann Sonarr im selben Pod nichts importieren, und `DOWNLOAD_FOLDER_PATH_MAPPING` muss auf genau diesen Pfad zeigen — eine Abweichung importiert schweigend nichts. `incomplete/` gehört **nicht** in einen emptyDir: ein emptyDir zählt gegen das ephemeral-storage-Limit des Containers, und ein großer Download lässt den kubelet den **ganzen Pod** räumen, mit allen neun anderen Containern. Das ist dieselbe Falle, die in ytdlp-web-player dokumentiert ist. **Image per Digest pinnen.** Die Tags sind unbrauchbar: `latest` stammt vom 12.11.2024 (= v0.2.5), die README empfiehlt `beta` (zuletzt 15.06.2026). Aufgelöst: ``` pcjones/mediathekarr:beta sha256:3ed7e1487810e1519301bd56a0c420e260e428295b029a47806c0397e4a52a33 ``` Single-Arch, **nur `linux/amd64`**, kein arm64 — gehört als Kommentar an die Stelle, auch wenn der Zielcluster durchgehend amd64 ist. Dazu eine Renovate-Regel für Digest-Updates, **im Trockenlauf belegt**: eine gültige Regel ist keine treffende Regel (#158, searxng-Runde). **Es gibt keinen Health-Endpunkt.** Gemessen 404 auf `/health`, `/healthz`, `/api/health`, `/download/health`, `/status`, `/ping`. Belegte 200er-Kandidaten für die Probes: - Port 5008: `GET /api?t=caps` - Port 5007: `GET /download/api?mode=version&output=json&apikey=x` oder `GET /download/` ## Offen, ausdrücklich ungemessen Ein Teil des Mediathek-Bestands liegt als **HLS-Playlist** (`application/x-mpegURL`) statt als progressives MP4 vor. MediathekArrs Downloader lädt eine einzelne HTTP-Datei und remuxt sie mit mkvmerge; ob er mit einer m3u8-Playlist umgehen kann, ist **nicht gemessen**. Falls nicht, fallen diese Einträge unabhängig von jeder Geosperre aus. Das gehört als offene Frage in `values.yaml`, nicht als Annahme in die eine oder andere Richtung. ## Zu belegen 1. **Der Chart rendert und installiert**, mit `mediathekarr.enabled: true` und `false`, ohne dass bestehende Installationen sich ändern. 2. **Das Startgate wirkt.** Zeigen, dass der Container nicht vor gluetuns Bereitschaft startet — und dass die Newznab-Suche danach Treffer liefert. Ein grüner Pod ist hier kein Beleg, weil der Fehlerfall grün aussieht. 3. **Die Probes.** Auf einem der belegten 200er-Pfade, nicht auf einem geratenen. 4. **Die Renovate-Digest-Regel im Trockenlauf.** 5. **Härtung wie gemessen**: nicht-root, uid 1000, `readOnlyRootFilesystem: true`. ## Versionsstufe **Minor** — rein additiv, standardmäßig aus, und der `volumeClaimTemplate` entsteht nur bei aktiviertem Flag, sodass sich für bestehende Installationen nichts ändert. Aktuell `3.0.5+up1.0.0`, also `3.1.0+up1.0.0`. Die `appVersion` des Charts bleibt unberührt: sie ist frei gewählt und an kein Upstream gebunden, alle Images sind in `values.yaml` gepinnt. Dazu wie üblich: `values.schema.json`, CI-Fixtures unter `ci/freesailarr/`, Renovate-Eintrag, README-Aktualisierung, wo sie repo-weites Verhalten berührt.
Author
Member

Kommentar von jk-cluster-bot am 2026-09-08 (migriert aus GitHub).


Korrektur am Auftragstext: DOWNLOAD_FOLDER_PATH_MAPPING gibt es im gepinnten Image nicht

Der Rumpf dieses Issues verlangt, DOWNLOAD_FOLDER_PATH_MAPPING auf den Pfad zeigen zu lassen, unter dem Sonarr das fertige Verzeichnis sieht. Diese Variable existiert im gepinnten beta-Image nicht.

Sie stammt aus der docker-compose.yml des Upstreams, und die beschreibt den latest-Stand von November 2024 (v0.2.5) — nicht den beta, auf den wir per Digest pinnen. Der Fehler ist meiner: ich habe die Betriebsdaten aus der Compose-Datei übernommen, ohne sie gegen das Image zu prüfen, das wir tatsächlich einsetzen.

Was stattdessen gilt: der beta liest DOWNLOAD_COMPLETE_PATH und DOWNLOAD_INCOMPLETE_PATH.

Die Absicht der Anforderung bleibt unverändert und ist bindend — der Pfad, den MediathekArr als fertig meldet, muss derselbe sein, den Sonarr im Pod sieht, sonst importiert Sonarr schweigend nichts. Umgesetzt wird sie mit den Variablen, die das Image liest, und der gemeldete complete_dir ist gegen die SABnzbd-API zu verifizieren statt anzunehmen.

Das ist zugleich eine Warnung für die nächste Runde an diesem Chart: Die Upstream-Dokumentation beschreibt einen zwei Jahre alten Stand. Was dort steht, gilt für unser Image erst, wenn es am Image belegt ist.

> Kommentar von **jk-cluster-bot** am 2026-09-08 (migriert aus GitHub). --- ## Korrektur am Auftragstext: `DOWNLOAD_FOLDER_PATH_MAPPING` gibt es im gepinnten Image nicht Der Rumpf dieses Issues verlangt, `DOWNLOAD_FOLDER_PATH_MAPPING` auf den Pfad zeigen zu lassen, unter dem Sonarr das fertige Verzeichnis sieht. **Diese Variable existiert im gepinnten `beta`-Image nicht.** Sie stammt aus der `docker-compose.yml` des Upstreams, und die beschreibt den `latest`-Stand von November 2024 (v0.2.5) — nicht den `beta`, auf den wir per Digest pinnen. Der Fehler ist meiner: ich habe die Betriebsdaten aus der Compose-Datei übernommen, ohne sie gegen das Image zu prüfen, das wir tatsächlich einsetzen. **Was stattdessen gilt:** der `beta` liest `DOWNLOAD_COMPLETE_PATH` und `DOWNLOAD_INCOMPLETE_PATH`. Die Absicht der Anforderung bleibt unverändert und ist bindend — der Pfad, den MediathekArr als fertig meldet, muss derselbe sein, den Sonarr im Pod sieht, sonst importiert Sonarr schweigend nichts. Umgesetzt wird sie mit den Variablen, die das Image liest, und der gemeldete `complete_dir` ist gegen die SABnzbd-API zu verifizieren statt anzunehmen. Das ist zugleich eine Warnung für die nächste Runde an diesem Chart: Die Upstream-Dokumentation beschreibt einen zwei Jahre alten Stand. Was dort steht, gilt für unser Image erst, wenn es am Image belegt ist.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#20