ontoserver: v0.5.2

0.5.2 (2026-08-14)

Fixed

• ontoserver: stop config passthroughs re-enabling writes on scaled deployments (fd908cd)

ontoserver: v0.5.1

0.5.1 (2026-08-13)

Fixed

• ontoserver: remove allowScaledReadWrite, scaled read-write is unsupported (5d5b97a)

ontoserver: v0.5.0

0.5.0 (2026-08-13)

Added

• ontoserver: expose OTel metrics and logs exporters (46a37e2)
• ontoserver: expose StatefulSet podManagementPolicy (f960874)

Fixed

• ontoserver: expose podManagementPolicy and OTel exporters, restore empty serverPort default (7cdff43)
• ontoserver: restore empty serverPort default (d76637a)

Documentation

• ontoserver: document podManagementPolicy, exporters and serverPort (95b54f4)
• ontoserver: regenerate README parameter tables (12f9c78)

ontoserver: v0.4.1

0.4.1 (2026-08-13)

Fixed

• exclude changelog.md by name instead of a helmignore negation (38cc427)
• unignore README.md in helm packages (1bdcd4e)

ontoserver-indexer: v0.2.1

0.2.1 (2026-08-13)

Fixed

• exclude changelog.md by name instead of a helmignore negation (38cc427)
• unignore README.md in helm packages (1bdcd4e)

ontoserver-extras: v0.1.2

0.1.2 (2026-08-13)

Fixed

• exclude changelog.md by name instead of a helmignore negation (38cc427)
• unignore README.md in helm packages (1bdcd4e)

ontoserver-indexer-0.2.0

Note: checked against the ontoserver-indexer-0.1.0 tag by diffing the values keys, not assembled from commit
messages, so nothing user-facing since that release is missing.

Added

• resources.heapGb — sets the JVM -Xmx independently of the container memory limit. The
  default is memoryGb - 2, leaving 2 GiB for non-heap JVM memory (metaspace, code cache,
  thread stacks, GC structures, direct buffers). Previously -Xmx was set equal to the memory
  limit, which guarantees an eventual OOMKill.
• Validation rejecting a heap that meets or exceeds resources.memoryGb, so the misconfiguration
  fails at install time rather than as an OOMKill mid-index.
• Opt-in security context: job.podSecurityContext, job.containerSecurityContext and
  job.automountServiceAccountToken, all unset by default so existing users see no change. The
  README documents a hardened configuration; note a non-root Job needs an fsGroup that can
  write the output PVC.
• job.extraVolumes and job.extraVolumeMounts — arbitrary volumes and mounts for the indexer
  container, rendered verbatim and appended after the chart's own output-volume/input-volume
  entries so those win a name collision. Both default to empty, so nothing changes for existing
  users. This makes readOnlyRootFilesystem: true reachable: the indexer runs the same Spring Boot
  image as the server and needs a writable /tmp, which the chart previously could not supply.

Fixed

• Registry credentials containing a " or \ no longer corrupt the image pull secret. The
  .dockerconfigjson was built by interpolating the username and password into a JSON string
  literal with printf, so either character produced invalid JSON — which the kubelet reports
  only as an opaque ImagePullBackOff. It is now built with dict and toJson.

Changed

• The default Job name is now <release name>-<release revision> rather than the release name,
  so an upgrade creates a new Job instead of failing on the immutable pod template of the
  existing one.

ontoserver-extras-0.1.1

Note: checked against the ontoserver-extras-0.1.0 tag by diffing the values keys, not assembled from commit
messages, so nothing user-facing since that release is missing.

Added

• Chart description corrected — it still advertised a PV template, which now lives in the
  ontoserver chart.

• collector.podSecurityContext and collector.containerSecurityContext. The collector pod is
  built by the OpenTelemetry Operator from the OpenTelemetryCollector CR, so these render as CR
  fields rather than pod-spec fields: spec.podSecurityContext and spec.securityContext — the
  latter being the container context despite the name. Both verified against the v1beta1 CRD
  shipped with operator 0.156.0. spec.containerSecurityContext, the plausible spelling, is not a
  field on the CRD. How that fails depends on the client, and both were tested against a live
  operator: kubectl apply rejects it with a strict decoding error, while Helm succeeds and the
  API server prunes the field — the release reports deployed and the collector runs with no
  container security context at all. The Helm path is the one that matters here and it is silent, so
  a test asserts the chart never emits that spelling.
  Validated on a cluster: the Operator (0.131.0) applies both contexts verbatim to the collector
  pod it builds, and the collector starts and runs under readOnlyRootFilesystem with all
  capabilities dropped.

• Readiness and liveness probes on the varnish container (varnish.probes.*, on by default).
  Only the metrics exporter sidecar had one before, so the Service began routing to a pod whose
  varnishd was not yet accepting connections and every rolling update dropped requests.

  Both are tcpSocket on the http port rather than httpGet. An HTTP probe would be proxied to
  Ontoserver: backend traffic on every period, and — worse — the cache marked unready whenever the
  backend was down, turning a backend outage into a cache outage and defeating the point of
  varnish.graceSeconds. The liveness probe is deliberately more tolerant than the readiness probe
  because a restart discards the whole cache.

  Note this is the one change here that is not pod-spec-neutral: the first upgrade rolls the
  Varnish Deployment once and the cache starts cold. Set varnish.probes.enabled: false to keep
  the previous behaviour.

• collector.batch.sendBatchSize and collector.batch.timeout, previously hardcoded.

• Opt-in security context: varnish.podSecurityContext, varnish.containerSecurityContext and
  varnish.automountServiceAccountToken. All default to unset, so upgrading an existing release
  leaves the pod spec byte-identical and does not discard a warm cache. The container-level value
  applies to every container in the pod — varnish, the metrics exporter and both trace sidecars —
  because they share a process namespace and are not independently isolatable.

Fixed

• Traces now actually ship. The batch processor was configured with timeout: 0s, which does not
  mean "flush immediately" — it disables the flush timer, so spans were held until
  send_batch_size (1000) accumulated. A terminology server is usually quiet, so the practical
  effect was that tracing appeared configured and nothing arrived. Now defaults to 5s, and a zero
  value is rejected at render time in any unit.

• The filter/health_checks processor now runs with error_mode: ignore. Its default,
  propagate, fails the entire batch when one condition errors, so a single span missing
  http.url would discard every span batched with it. The three cache_lookup conditions were
  also missing the nil guard the surrounding conditions already had — and a condition that errors
  is one that never matches, so the spans it should have filtered were being exported.

• Varnish now restarts when its VCL changes. varnishd parses /etc/varnish/default.vcl once
  at startup and never re-reads the mounted ConfigMap, so a helm upgrade that changed only a
  cache setting updated the ConfigMap, left the pod template untouched, and Varnish went on
  serving the previous VCL indefinitely. The Deployment pod template now carries a
  checksum/config annotation over the rendered VCL. Note this means upgrading to this version
  restarts Varnish once, discarding the warm cache.

Changed

• The VCL body moved from varnish-configmap.yaml into a named template
  (ontoserver-extras.varnish.vcl) so the Deployment can hash exactly the VCL text. The
  rendered ConfigMap content is unchanged. The hash is deliberately independent of the chart
  version, so future releases do not restart Varnish without a VCL change.
• Chart icon URL now points at the master branch rather than the non-existent main.

ontoserver-0.4.0

Removed

• BREAKING: the bundled nginx-ingress subchart. The chart no longer installs an ingress
  controller. It was pinned at 2.1.0 and nobody was updating it, which makes a vendored
  network-facing controller a liability rather than a convenience.

  Migration. Install a controller yourself and point the chart at its IngressClass:

  helm repo add nginx-stable https://helm.nginx.com/stable
  helm install nginx-ingress nginx-stable/nginx-ingress \
    --namespace nginx-ingress --create-namespace \
    --set controller.ingressClass.name=ontoserver-nginx

  ontoserver:
    ingress:
      enabled: true
      className: ontoserver-nginx   # must match the controller's IngressClass
  # delete the whole nginx-ingress: block

  The chart fails to render if a nginx-ingress: block is still present — including
  enabled: false. That is deliberate: nothing at the top level of values.schema.json sets
  additionalProperties: false, so the key would otherwise be accepted silently and helm upgrade
  would quietly stop deploying the controller, taking the service offline with no error anywhere.
  The presence of the key, not its value, is the signal that a values file has not been migrated.

  Consequences worth knowing: the chart now has no dependencies at all, so Chart.lock and the
  vendored charts/ directory are gone and helm dependency build is a no-op.

Note: verified against the ontoserver-v0.3.0 tag rather than assembled from commit messages —
18 commits touch this chart since that release, and the values-key diff was used to confirm
nothing user-facing is missing. Changes predating 0.3.0 are covered by the sections below.

Added

• ontoserver.gateway.allowPlaintext and ontoserver.gateway.listenerPortPlain. A plaintext HTTP
  listener now has to be requested explicitly: it is off by default so a public Gateway cannot be
  left unencrypted by accident. Enable it for local development, or when TLS terminates upstream.

• ontoserver.gateway.closureRequestTimeout (default 300s). The $closure HTTPRoute carried no
  timeouts block at all, so the chart's longest-running operation inherited whatever the Gateway
  implementation defaults to. Falls back to requestTimeout when empty.

• ontoserver.metrics.serviceMonitor.labels, .interval, .scrapeTimeout and
  .namespaceSelector. Most Prometheus installations set a non-empty serviceMonitorSelector, and
  a ServiceMonitor carrying no matching label is silently never discovered — nothing errors, the
  metrics just never appear.

• Validation of the release-name length, with the limits checked against a live API server. The
  binding constraint is Service names (DNS labels, capped at 63), which caps the release name at
  33 — Helm's own cap of 53 is not low enough. Without this an over-long name yields a
  partially installed release: everything applies except one Service.

• ontoserver.deployment.allowScaledReadWrite — opt in to the unsupported scaled read-write
  topology. Scaled deployments must otherwise be read-only: each replica keeps its own Lucene
  index on its own PVC, so content written through the round-robin Service is indexed only on
  the replica that served the write, and $expand/$validate-code then fail on the others.

• ontoserver.deployment.podDisruptionBudget.maxUnavailable and .unhealthyPodEvictionPolicy
  as real values rather than commented-out suggestions.

• Opt-in security context: ontoserver.deployment.podSecurityContext,
  .containerSecurityContext, .db.containerSecurityContext and .automountServiceAccountToken.
  The chart previously set no security context anywhere, so pods ran as root. All four default to
  unset, so upgrading an existing release renders a byte-identical pod spec and rolls no pods —
  hardening has to be requested. The Postgres sidecar has its own value because it cannot share
  the Ontoserver container's: the postgres entrypoint requires uid 999.

  A verified hardened configuration is documented in the README, along with the two
  combinations that cannot be made to work non-root (the Postgres sidecar and Ontoserver's own
  HTTPS mode). Those constraints were established by running the shipped images under each
  setting, not inferred — each failure is a crash at startup.

• ontoserver.deployment.extraVolumes and .extraVolumeMounts — arbitrary volumes and mounts for
  the Ontoserver container, rendered verbatim and appended after the chart's own entries so
  chart-managed names always win a collision. Both default to empty, so an existing release
  renders a byte-identical pod spec.

  This makes readOnlyRootFilesystem: true reachable, which it previously was not: the server
  needs a writable /tmp and the chart had no way to supply one. Validated on a cluster (AKS,
  external PostgreSQL, Gatekeeper auditing): Ready in ~50s with 0 restarts, root filesystem
  genuinely read-only, FHIR served, both helm test suites passing, and zero violations of
  readOnlyRootFilesystem, allowedUsersGroups or noPrivilegeEscalation for the namespace. /tmp turned out to be
  load-bearing rather than just a log destination — a running server writes spring.log,
  hsperfdata, Tomcat's work directories and downlaod-* scratch files there. The hardened
  README recipe now includes both, asserted together by a test so it cannot ship half-applied.

• Schema validation and test coverage for ontoserver.existingSecretConfig, a 0.3.0 feature that
  shipped with neither. The value was accepted before (the schema has no additionalProperties
  restriction at that level) so this is validation and documentation rather than a functional fix:
  a non-string is now rejected with a message naming the key.

Fixed

• Documented a silent $closure routing failure on Traefik. Traefik matches PathPrefix against
  the percent-encoded path, so a client sending /fhir/%24closure misses the dedicated pod-0 route
  and is load-balanced across all pods, corrupting the stateful closure table. NGINX decodes before
  matching and is unaffected. Both were tested; AWS ALB and Azure AGIC remain unverified and the
  README says so.

• Removed the unreachable existingVolume branch from the StatefulSet's volumeClaimTemplates.
  validate-values.yaml rejects persistence.files.existingVolume for a StatefulSet outright, so
  the branch could never render — and the spec it would have produced (volumeName with no
  accessModes or resources) was not a valid PVC. Renders are byte-identical across all eight
  test fixtures.

• Renamed poddistributionbudget.yaml to poddisruptionbudget.yaml (the resource is a
  PodDisruptionBudget). Template filenames are not part of the API, so this changes nothing at
  install time.

• A Deployment with persistence on a ReadWriteOnce volume now renders strategy.type: Recreate
  instead of the requested RollingUpdate. RollingUpdate cannot work there: it starts the
  replacement pod before removing the old one, and a RWO disk attaches to one node at a time, so a
  replacement scheduled elsewhere waits indefinitely on Multi-Attach error while the old pod is
  never torn down. Reproduced on a live cluster; it also blocks PVC expansion until the volume
  detaches. Scoped to ReadWriteOnce/ReadWriteOncePod, so ReadWriteMany users keep
  zero-downtime rolling upgrades, and the sidecar's dbfiles access mode is only consulted when
  the sidecar is enabled.

  Upgrading an existing release: Kubernetes defaults spec.strategy.rollingUpdate and refuses
  to hold it alongside type: Recreate. helm upgrade and client-side kubectl apply handle the
  removal; server-side apply fails with spec.strategy.rollingUpdate: Forbidden. Each row of
  that was verified on a cluster, and the README gives the one-line patch that clears it.

• ontoserver.secretConfig no longer fails to render on a non-string value. b64enc rejects
  anything but a string, so a numeric port or a boolean flag aborted the whole release with
  wrong type for value; expected string; got int64 — and the error named only <b64enc>, not the
  key at fault. Values are now coerced with toString, matching the sibling ontoserver.config,
  which has always accepted them via | quote. Note that Helm parses YAML numbers as float64, so
  quote any value whose exact form matters; that is true of both keys and is not new.

• envoygateway.envoyProxy.pdbMinAvailable: 0 and .replicas: 0 are no longer silently coerced to
  1 and 2. Both were rendered with | default, and 0 is falsy in Go templates, so the Envoy fleet
  could not be scaled to 0 and its PodDisruptionBudget could not be set to permit full eviction.
  Same class of bug as the PodDisruptionBudget fix above. minAvailable now also routes through the
  shared IntOrString helper for consistency, though the quoting is not load-bearing in this field.

• podDisruptionBudget.minAvailable/.maxUnavailable now accept percentages. The previous guard
  compared int against 1, and int "25%" is 0, so every percentage — including the 25% form
  the values file suggested — was rejected. Percentages are emitted quoted and counts unquoted,
  as the Kubernetes IntOrString type requires. Setting both, setting neither, maxUnavailable: 0,
  and a minAvailable at or above the replica count are now all rejected with an actionable
  message instead of silently producing an unevictable workload.

• Configuration changes now roll the pods. checksum/secret-config and
  checksum/external-secret annotations were added to the pod template, because Ontoserver
  resolves its configuration as environment variables at container start, so a helm upgrade
  that changed only a Secret left the running pods on the old value indefinitely. See
  "Configuration changes and pod restarts" in the README for what is and is not covered.

• The `-ontoserver-db...

ontoserver-0.3.0

Added

• existingSecretConfig — reference a pre-existing Kubernetes Secret by name; its keys are injected as environment variables via envFrom, enabling GitOps workflows (e.g. ArgoCD) where secrets are managed outside the chart.
• Chart-native External Secrets support for registry credentials via ontoserver.externalSecret.imagePullSecret.
• Automatic wiring of the generated external pull secret into workload imagePullSecrets for both Deployment and StatefulSet modes.
• Optional secretStoreRef overrides for the image pull secret, allowing registry credentials to come from a different secret store than other external secrets.
• Unit test coverage for external pull secret rendering, workload wiring, and validation behaviour.

Changed

• Replaced the manual ExternalSecret-based quay.io pull-secret example with the chart-managed externalSecret.imagePullSecret workflow in the chart documentation.

Fixed

• Added render-time validation to require both imagePullSecret.data.username.key and imagePullSecret.data.password.key to be set together.
• Added render-time validation to block the unsupported combination of certmanager.enabled=true with ALB ingress.