Run both ro and rw integration tests and clarify vartnish closureBackend

Author: attilaedelenyi

.github/workflows/integration-tests.yml

@@ -6,8 +6,22 @@ on:
 
 jobs:
   integration-tests:
-    name: Integration Tests
+    name: Integration Tests (${{ matrix.mode.name }})
     runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        mode:
+          - name: read-only
+            release: ontoserver-ro
+            isReadOnly: "true"
+            expectedHook: ontoserver-ro-ontoserver-test-fhir-ro
+            unexpectedHook: ontoserver-ro-ontoserver-test-fhir-rw
+          - name: read-write
+            release: ontoserver-rw
+            isReadOnly: "false"
+            expectedHook: ontoserver-rw-ontoserver-test-fhir-rw
+            unexpectedHook: ontoserver-rw-ontoserver-test-fhir-ro
     steps:
       - uses: actions/checkout@v4
 
@@ -30,8 +44,8 @@ jobs:
 
       - name: Install chart
         run: |
-          helm install ontoserver ./charts/ontoserver \
-            --set ontoserver.deployment.isReadOnly=false \
+          helm install ${{ matrix.mode.release }} ./charts/ontoserver \
+            --set ontoserver.deployment.isReadOnly=${{ matrix.mode.isReadOnly }} \
             --set ontoserver.managementService.enabled=true \
             --set ontoserver.imageCredentials.username=${{ secrets.QUAY_USERNAME }} \
             --set ontoserver.imageCredentials.password=${{ secrets.QUAY_PASSWORD }} \
@@ -56,23 +70,33 @@ jobs:
           echo "=== Pod description ==="
           kubectl describe pods
           echo "=== Pod logs ==="
-          kubectl logs -l app=ontoserver-ontoserver --all-containers=true --tail=100 || true
+          kubectl logs -l app=${{ matrix.mode.release }}-ontoserver --all-containers=true --tail=100 || true
           echo "=== Events ==="
           kubectl get events --sort-by='.lastTimestamp'
 
       - name: Run integration tests
-        run: helm test ontoserver --timeout 10m
+        run: helm test ${{ matrix.mode.release }} --timeout 10m
+
+      - name: Verify mode-specific test hook rendered
+        run: |
+          kubectl get job ${{ matrix.mode.expectedHook }}
+          if kubectl get job ${{ matrix.mode.unexpectedHook }} >/dev/null 2>&1; then
+            echo "Unexpected Helm test job found: ${{ matrix.mode.unexpectedHook }}"
+            exit 1
+          fi
 
       - name: Collect test logs
         if: always()
         run: |
           echo "=== Events ==="
           kubectl get events --sort-by='.lastTimestamp'
           echo "=== Ontoserver pod logs (all containers) ==="
-          kubectl logs -l app=ontoserver-ontoserver --all-containers=true --tail=50 || true
+          kubectl logs -l app=${{ matrix.mode.release }}-ontoserver --all-containers=true --tail=50 || true
           echo "=== test-metadata job ==="
-          kubectl describe job ontoserver-ontoserver-test-metadata || true
+          kubectl describe job ${{ matrix.mode.release }}-ontoserver-test-metadata || true
           echo "=== test-metadata logs ==="
-          kubectl logs -l job-name=ontoserver-ontoserver-test-metadata --tail=200 || true
-          echo "=== test-fhir-rw logs ==="
-          kubectl logs -l job-name=ontoserver-ontoserver-test-fhir-rw --tail=200 || true
+          kubectl logs -l job-name=${{ matrix.mode.release }}-ontoserver-test-metadata --tail=200 || true
+          echo "=== mode-specific test job ==="
+          kubectl describe job ${{ matrix.mode.expectedHook }} || true
+          echo "=== mode-specific test logs ==="
+          kubectl logs -l job-name=${{ matrix.mode.expectedHook }} --tail=200 || true

charts/ontoserver-extras/README.md

@@ -178,10 +178,12 @@ When Varnish fronts a scaled StatefulSet Ontoserver cluster, two additional sett
 
 **`varnish.graceSeconds`** — Seconds to serve stale cached content when the backend is temporarily unavailable (default `30s`). This covers rolling updates of the Ontoserver StatefulSet: while a pod is being replaced, Varnish continues serving its last-known response rather than returning a 503. Set to `0` to disable grace mode.
 
-**`varnish.closureBackend`** — The [`$closure` FHIR operation](https://www.hl7.org/fhir/conceptmap-operation-closure.html) is stateful and must always reach the same Ontoserver instance. When set, Varnish routes all `POST /fhir/ConceptMap/$closure` requests to this specific backend hostname, bypassing the cache and the normal load-balanced backend. Set to the stable DNS name of pod-0 via the headless service (e.g. `RELEASE-statefulset-0.RELEASE-ontoserver-headless`). Empty string (the default) disables dedicated `$closure` routing.
+**`varnish.closureBackend`** — Optional dedicated backend for the [`$closure` FHIR operation](https://www.hl7.org/fhir/conceptmap-operation-closure.html), which is stateful and must always reach the same Ontoserver instance. When set, Varnish routes all `POST /fhir/ConceptMap/$closure` requests to this specific backend hostname, bypassing the cache and the normal load-balanced backend. Set it to the stable DNS name of pod-0 via the headless service (e.g. `RELEASE-statefulset-0.RELEASE-ontoserver-headless`). Empty string (the default) disables dedicated `$closure` routing.
 
 > [!IMPORTANT]
-> When Varnish is the entry point for a scaled StatefulSet deployment (i.e. `ontoserver.gateway.backendServiceNameOverride` or `ontoserver.ingress` routes traffic to the Varnish service), you **must** set `varnish.closureBackend`. Without it, `$closure` requests are load-balanced across all pods and will fail intermittently because each pod maintains its own independent closure table state.
+> You usually do **not** need `varnish.closureBackend` when using the `ontoserver` chart's Gateway or Ingress. In that setup, the `ontoserver` chart already routes `/fhir/ConceptMap/$closure` directly to `RELEASE-ontoserver-pod0-service` before the catchall route to Varnish, so `$closure` bypasses Varnish entirely.
+>
+> Set `varnish.closureBackend` only when clients send `$closure` requests to Varnish directly, bypassing the `ontoserver` chart's Gateway/Ingress path-based routing. That is a niche setup, such as port-forwarding or exposing Varnish through a separate ingress/proxy in front of the Ontoserver chart. Without `varnish.closureBackend`, Varnish forwards `$closure` to its normal backend service, which load-balances across all Ontoserver pods and breaks the stateful closure table.
 >
 > Set it to the stable pod-0 DNS name:
 > ```yaml

charts/ontoserver/README.md

@@ -478,7 +478,7 @@ Ready-to-use ArgoCD Application manifests are in [`examples/argocd/`](../../exam
 
 The ArgoCD examples use multi-source Applications with both the `ontoserver` and `ontoserver-extras` charts as sources, wired together so that enabling Varnish automatically routes the Ingress through it. See the [extras chart README](../../charts/ontoserver-extras/README.md#deploying-alongside-the-ontoserver-chart) for the wiring details.
 
-> **Note:** The GitHub Actions CI integration tests use a similar k3d setup (single agent, no load balancer, Traefik disabled) to run `helm install` followed by `helm test`. See [`.github/workflows/ci.yml`](../.github/workflows/ci.yml) for details.
+> **Note:** The GitHub Actions integration workflow uses a similar k3d setup (single agent, no load balancer, Traefik disabled) to run `helm install` followed by `helm test` in both read-only and read-write modes. See [`.github/workflows/integration-tests.yml`](../.github/workflows/integration-tests.yml) for details.
 
 ## Parameters