Release Notes – Trinity Platform v4.10.0

Neutrinos Platform Product Release Notes
, ,
1

:clipboard: Overview

Trinity 4.10.0 is a large feature release focused on the deployment experience and application health. The deployment/upgrade screens and the post-deployment (deployment details) screens have both been redesigned, applications can now be configured with health probes, and database migrations during deployment now run with full audit tracking.

Upgrade note: This release includes database schema changes (probes versioning, migration tracking). Run the 4.10.0 SQL script (release-4.10.0.sql) before upgrading.

:sparkles: Highlights

  • New deployment & upgrade screens — redesigned deploy flow with tree-structured values editing, values comparison, and a review summary.

  • New post-deployment screens — redesigned deployment details with health, workloads, pods, infrastructure, logs, history, and migration.

  • Application health probes — configure readiness/liveness/startup probes; API apps get a default readiness probe on /healthcheck.

  • Audited database migrations — migrations run as isolated jobs with every step recorded.

  • Infrastructure health — storage, secrets, node disk, and recent pod errors visible in the console.

:rocket: 1. New Deployment & Upgrade Screens

The screens used to deploy and upgrade an asset have been redesigned end-to-end for a clearer, safer flow:

  • Deployment destination — a clearer step for choosing where the asset is deployed (environment / namespace / release).

Create Deployment — Configuration step: Deployment Destination
Create Deployment — Configuration step: Deployment Destination1893×843 74.2 KB

  • Redesigned Domain, CRS, and Additional Configurations sections — these three steps of the deploy flow have a refreshed layout:

  • Domain — specify the domain for the deployment.

  • CRS — create container registry secrets to pull images from a private registry.

  • Additional Configurations — configure optional storage and secrets.

These are visual/UX updates only — there are no functional changes to how they are configured.

  • Tree-structured values — values files are now presented and edited as a structured tree rather than only raw YAML. Edits are guided by the selected version’s schema, making configuration updates safer and less error-prone. YAML syntax errors are still shown with their location, and the Deploy button stays disabled until the file is valid.

Configuration step — sections list and tree-structured values editor
Configuration step — sections list and tree-structured values editor1893×843 93.9 KB

  • Values comparison — compare the currently deployed values side-by-side with the new version’s values before deploying.

Configuration Changes — marketplace vs current values diff (tree view)
Configuration Changes — marketplace vs current values diff (tree view)1893×843 77.8 KB

  • DB Migrations section — configure the database connection details for the deployment. The section itself is unchanged, but it can now take and validate its values through the new AJV schema validation used across the deploy flow.

Review & Deployment Summary

The deploy flow is now a two-step wizard — Configuration → Summary — with a new Summary (Review) page that lets you review everything in one place before deploying:

  • Deployment destination — environment, namespace, release name, version, and deployment timeout, with a Configuration Status indicator (e.g. Valid).

  • Values — when the configuration differs from what is currently deployed, a comparison view highlights what changed (previous vs. new); when nothing changed, the full searchable, paginated list of current values is shown (with a “deploying with current configuration” note).

  • DB Migration — the database-migration values are shown the same way: a comparison of what changed when the config differs, or the full list when it doesn’t.

  • Add comment — attach a note that appears on the deployment details page for easy reference.

  • Helm Template — preview the rendered Helm template before deploying.

  • Back / Cancel deployment / Deploy actions; each section has an Edit link to jump back and change it.

Create Deployment — Summary (Review) page
Create Deployment — Summary (Review) page1893×843 70.5 KB

When you click Deploy

When you click Deploy, the database migration for the deployment now runs as an isolated Kubernetes Job on the controller cluster, which captures all migration error logs (see §4).

:desktop_computer: 2. New Post-Deployment (Deployment Details) Screens

The deployment details page has been rebuilt around a tabbed layout that brings health, configuration, and lifecycle management together:

  • Overview — the landing tab, giving a live health picture of the deployment. It shows pod health cards with readiness/liveness/startup probe status, a searchable pod list, and running counts of healthy / warning / error pods. It also surfaces a unified critical-errors feed (combining infrastructure and application errors) and an embedded comparison of the deployed values against the new configuration.

Deployment details — Overview tab (Service Health Checks)
Deployment details — Overview tab (Service Health Checks)1893×843 140 KB

  • Workloads — lists every Kubernetes controller in the release (Deployments, StatefulSets, DaemonSets). For each workload you can scale replicas, edit CPU/memory resources, run describe, and view logs — all inline. The table is searchable by name, kind, or image.

  • Pods — functionally the same as before (per-pod health, age, restarts, service, images, describe, and logs), but with an improved UI. Health badges make the pod phase (Running / Pending / Failed) obvious at a glance.

  • Infrastructure — surfaces cluster-level health for the deployment’s namespace. Storage shows node disk usage and PVC capacity with the workloads/pods consuming each volume; access resources lists secrets, registry, and domain consumers; and a recent-errors feed shows pod warning events with severity filtering. A live error/warning count badge appears on the tab.

Deployment details — Infrastructure Health tab
Deployment details — Infrastructure Health tab1893×843 168 KB

  • Error Logs — aggregates the application’s error logs into a single feed showing the error, source pod/service, timestamp, and severity. It handles both JSON and plain-text logs, and provides a deep-link into SigNoz for deeper analysis.

Deployment details — Error Logs tab (View in SigNoz)
Deployment details — Error Logs tab (View in SigNoz)1893×843 127 KB

  • History — a chronological changelog of every deployment for the asset, each with its status (Success / Failure / In Progress), the user who triggered it, the version, and a timestamp. Entries expand to show step-by-step execution detail (and error details on failure), with links into the Migration tab when a migration ran.

Deployment details — History tab
Deployment details — History tab1893×843 200 KB

  • Migration — the migration asset has been upgraded (and still supports older/existing migrations), and this tab now shows the complete migration run. It renders an overview header (environment, database, and overall status) followed by every SQL step executed, in order — each statement along with its step title and metadata, and for any failed step a “Failure Detected” block with the error code, message, and details. The whole log is shown in a read-only Monaco editor with SQL highlighting (failures in red, success/restored in green). If a rollback ran, a Recovery Summary reports the migration vs. rollback status, whether the database was RESTORED or FAILED, and flags manual review as required.

Deployment details — Migration tab (SQL execution history in Monaco editor)
Deployment details — Migration tab (SQL execution history in Monaco editor)1893×843 195 KB

:stethoscope: 3. Application Health Probes

Applications can now be configured with Kubernetes readiness, liveness, and startup probes, per application and per version.

  • API apps get a readiness probe enabled by default on /healthcheck (auto-added at deploy time unless disabled).

CI/CD: the build pipelines (new Jenkins 4100 pipeline and the updated Azure pipeline) now detect the /healthcheck endpoint and set a healthcheck_endpoint_exists flag on the build, which is what drives the default readiness probe for API apps.

Schema: the 4.10.0 SQL script adds a version_name column to probes_application and backfills existing rows so probes can be scoped per version.

:file_cabinet: 4. Audited Database Migrations

Database migrations that run during asset deployment have been reworked to run as an isolated, ephemeral Kubernetes Job with full audit tracking:

  • The migration app has been updated with new audit logging — it records every SQL query as it executes and captures all error logs, so the full migration run (each query, passed or failed) is visible.

  • Failures are captured with their reason, including infrastructure failures such as image-pull/registry-credential (regcred) errors, storage issues, insufficient resources, and OOM.

  • Trinity now decides automatically whether a migration is needed when you deploy — there is no manual “skip migration” option anymore. If the deployed version already matches the target, the migration is skipped on its own; if the deployment fails after a migration runs, it is rolled back automatically.

Operator note: Because the migration now runs as a Job on the controller cluster, the target database must be reachable from the controller cluster and the database credentials/rights used for migrations must be granted on the controller cluster as well (previously they only needed to work from the runtime side). Ensure the controller cluster has network access to the database and the migration user has the required privileges.

Environment variables (backend/trinity-deployments/environments/*.env):

Variable Default Purpose
MIGRATION_JOB_NAMESPACE monitoring Namespace where migration Jobs run.
MIGRATION_APP_PORT 7200 Port the migration app serves on.
MIGRATION_APP_IMAGE_PULL_SECRET migration-app-regcred Pull secret for the migration app image.
MIGRATION_JOB_ACTIVE_DEADLINE_SECONDS 900 Hard time limit for a migration Job.
MIGRATION_JOB_STARTUP_TIMEOUT_SECONDS 120 Startup budget before fast-fail.
RUN_AS_JOB true Run the migration app in Job mode.

:bar_chart: 5. Infrastructure Health

The Infrastructure tab surfaces cluster-level health directly in the console:

  • Storage — PVC status, capacity/usage, consumers, and per-node disk usage.

  • Access resources — secrets, TLS/domain secrets, and registry secrets, with their consuming pods.

  • Recent errors — pod warning events grouped by workload, with severity filtering.

Cloud-provider auth (GKE/AKS/EKS/OKE) is now cached per cluster session, speeding up these views.

Variable Default Purpose
INFRA_HEALTH_NODE_CONCURRENCY 20 Max concurrent node-stat fetches.
K8S_AUTH_CACHE_TTL_SEC 3300 Per-cluster auth cache TTL.

:shopping_cart: 6. Marketplace Safeguards

  • On upgrade, docker-image values are always taken from the marketplace so a version upgrade deploys the new image instead of silently reusing the old one. A new DOCKER_IMAGE_KEYS setting on trinity-asset-orchestrator lists the image-related value paths (registry, repository, tag, version, etc.) that are forced from the marketplace during the values merge.

:wrench: Upgrade Steps

  1. Back up the console database.
  2. Run the 4.10.0 SQL script (release-4.10.0.sql) — probes versioning + migration tracking.
  3. Set/adjust environment variables in backend/trinity-deployments/environments/<env>.env:
    • Migration: MIGRATION_JOB_NAMESPACE, MIGRATION_APP_PORT, MIGRATION_APP_IMAGE_PULL_SECRET, MIGRATION_JOB_ACTIVE_DEADLINE_SECONDS, MIGRATION_JOB_STARTUP_TIMEOUT_SECONDS, RUN_AS_JOB.
    • Infra health: INFRA_HEALTH_NODE_CONCURRENCY, K8S_AUTH_CACHE_TTL_SEC.
  4. Grant the migration database rights on the controller cluster and ensure the controller cluster can reach the database (migrations now run there — see §4).
  5. Upgrade the console-helm-charts and deploy the updated images for all Trinity services.
  6. Verify: deployment and details screens load, probes appear per version, migrations run as Jobs and are audited, and a version upgrade deploys the new image.

:spouting_whale: Docker Images

Release Branch: release/4.10.0
Registry: neutrinos.azurecr.io

# Repository Name Docker Image Tag
1 trinity-frontend (UI) neutrinos.azurecr.io/trinity/trinity-frontend/ui 26.06.4.10.0
2 trinity-frontend (API) neutrinos.azurecr.io/trinity/trinity-frontend/api 26.06.4.10.0
3 trinity-orchestrator neutrinos.azurecr.io/trinity/trinity-orchestrator 26.06.4.10.0
4 trinity-db-operations neutrinos.azurecr.io/trinity/trinity-db-operations 26.06.4.10.0
5 trinity-deployments neutrinos.azurecr.io/trinity/trinity-deployments 26.06.4.10.0
6 trinity-promscale-connector neutrinos.azurecr.io/trinity/trinity-promscale-connector 26.06.4.10.0
7 trinity-alerts-email-service neutrinos.azurecr.io/trinity/trinity-alerts-email-service 26.06.4.10.0
8 trinity-app-logs neutrinos.azurecr.io/trinity/trinity-app-logs 26.06.4.10.0
9 trinity-assets-orchestrator neutrinos.azurecr.io/trinity/trinity-assets-orchestrator 26.06.4.10.0
10 alerts-base-app (runtime) neutrinos.azurecr.io/trinity/alerts-base-app 26.06.4.10.0

:memo: Summary

Category Included in 4.10.0
New features Redesigned deployment/upgrade screens; redesigned deployment-details screens; application health probes; audited database migrations; infrastructure health.
Improvements Tree-structured values editing; deployed-vs-new values comparison; per-session kubectl auth caching; SigNoz log deep-link.
Fixes YAML syntax surfacing; schema-filtered validation; correct image on upgrade; same-version migration skip.
Migration required :white_check_mark: Run release-4.10.0.sql and set new env vars before upgrading.