Global View upgrade (2025.10.1)
As part of the 2025.10.1 release, several infrastructure components were modernized and moved to different Helm charts/operators to mitigate CVEs and modernize the stack.
Important
This upgrade involves data migration. Follow the upgrade instructions carefully.
Component | Old deployment | New deployment | Updates |
|---|---|---|---|
Redis | Bitnami Redis Helm chart | PascalIske Redis Helm chart | Requires PVC reuse during upgrade |
Kafka | Bitnami Kafka Helm chart | Strimzi Kafka Operator | Operator-based Kafka |
PostgreSQL | Bitnami PostgreSQL Helm chart | CloudNativePG (Cloud Native PostgreSQL) | Operator-based and migration workflow introduced |
New Helm tags introduced
New Helm tags were added to support operator-based components and migration workflows.
Tag | Purpose | What Gets Installed |
|---|---|---|
tags.crds=true | Install required CRDs and operators | Strimzi and CloudNativePG CRDs are installed and also deploys the CloudNativePG operator. |
tags.migrations=true | Perform PostgreSQL migration | Deploys a temporary PostgreSQL migration cluster to migrate data from Bitnami PostgreSQL. |
tags.infra=true | Deploy infra layer | Installs Kafka cluster, KafkaNodePools, CloudNativePG main cluster, and other infra components. |
tags.service=true | Deploy service layer | Installs service layer components only. |
PostgreSQL migration flow
The migration runs in two import stages:
Bitnami PostgreSQL migration to Temporary migration cluster
As a part of migration process (
tags.migrations=true), a temporary PostgreSQL cluster is created for migration.An import job copies data from Bitnami PostgreSQL into the migration cluster with import pod name format as
pg-migration-cluster-1-import-xxxxx.This import pod runs for a short duration, depending on size of the data to be migrated.
After successful import, the import pod is deleted automatically. A new pod appears as
pg-migration-cluster-1.Do not proceed to infra deployment until
pg-migration-cluster-1isRunning.
Temporary migration cluster migration to CloudNativePG cluster
When infra deployment is triggered (tags.infra=true), the main PostgreSQL cluster is created. Another import job runs to import data from the temporary migration cluster with import pod name format as
controlplane-infra-postgresql-main-1-import-xxxxx.After successful import, the import pod is deleted automatically.
The main database pod appears as
controlplane-infra-postgresql-main-1. Wait for the pod to be inRunningstate before deploying service components.
Changes in the Helm values
When upgrading to this release, several Helm chart dependencies have changed. The sections below describe the required modifications to your existing global-view-values.yaml file to ensure a smooth upgrade with no data loss and correct resource configuration.
Redis: Reuse the existing PVC
During upgrade, Redis has moved charts, so you must point the new deployment to the existing PVC created by the older Bitnami Redis deployment.
It prevents data loss by reusing the existing Redis persistent volume claim instead of creating a new empty one.
Add the following snippet to your existing global-view-values.yaml:
redis:
persistentVolumeClaim:
existingPersistentVolumeClaim: "redis-data-controlplane-infra-redis-master-0"PostgreSQL: storage/auth moved to global.postgresql
Bitnami PostgreSQL is removed. PostgreSQL storage sizing and auth are now configured under global.postgresql.
It controls storage sizing for CloudNativePG-based deployments. During migration/upgrade, two PVCs will be created, where one used by the temporary migration cluster (tags.migrations=true) and other one used by the main PostgreSQL cluster (tags.infra=true).
Add the following snippet to your existing global-view-values.yaml:
global:
postgresql:
storage:
size: 8Gi
auth:
postgresPassword: ""The other configurations like resources, affinity etc. have been removed from postgresql: and is now available under cloud-native-postgresql-cluster:. It controls CloudNativePG cluster sizing, image version, and resource usage.
cloud-native-postgresql-cluster:
instances: 1
image:
registry: ghcr.io
repository: cloudnative-pg/postgresql
pullPolicy: IfNotPresent
tag: "16.11-standard-trixie"
resources:
requests:
cpu: 100m
memory: 512Mi
limits:
cpu: 500m
memory: 512Mi
afinity: {}Prepare the Helm Values File
Create a new file named global-view-values.yaml. Replace all placeholder values with your environment-specific settings.
Global Configuration
global:
controlplane:
ingress:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
postgresql:
migration:
enabled: true
storage:
size: 50Gi
environment: app
secret_source: valuesfile
storageClass: &defaultStorageClass ""
dockerRegistryCredentials:
DOCKER_SERVER: "https://index.docker.io/v2/"
DOCKER_USERNAME: "username"
DOCKER_PASSWORD: "password"
keycloak:
hostname: <KEYCLOAK_HOSTNAME>
adminUser: "vpadmin"
adminPassword: "P@ssW0rd@123"
public_dns_host_name: <global_view_hostname>
public_dns_host_am_suffix: -oc-<global_view_hostname>
organization_details:
organization_name: "<TENANT_NAME>"
first_name: "John"
last_name: "Doe"
contact_email: "xxxx.xxxx@domain.com"
create_tls_selfsigned_certs: true
affinity: &affinity {}
nodeSelector: &nodeSelector {}
tolerations: &tolerations []The following table describes each field in the configuration file.
Field | Description | Default value |
|---|---|---|
| Controls the behavior of the NGINX Ingress for the control plane. | |
| Controls automatic HTTP to HTTPS redirection. The default value decides the outcome. | false |
| Diables all incoming traffic to be served via HTTPS. | false |
| Represents the deployment environment name or type. | app |
| Specifies where secrets should come from. | valuesfile/none |
| Default Kubernetes StorageClass name for PVCs. | &defaultStorageClass "" |
| Credentials to pull container images from a Docker registry. | |
| If you are deploying in an air gapped environment and using a private docker registry to pull container images then use private registry URL. | https://index.docker.io/v2/ |
| Private registry username. | "username" |
| Private registry password | "password" |
| Integrates the platform with a Keycloak identity provider. | |
| Public hostname where Keycloak is accessible | <KEYCLOAK_HOSTNAME> |
| Credentials for the Keycloak admin account used to configure realms, clients, or users for this platform. | |
| Main DNS name for accessing the Virtana Global View UI. | <GLOBAL_VIEW_HOSTNAME> |
| Suffix used to construct additional hostnames, likely for auxiliary or AM services. | -oc-<global_view_hostname> |
| Metadata about the tenant or organization | |
| Tenant or company name | <TENANT_NAME> |
| Primary contact person | |
| Contact email for notifications or support | xxxx.xxxx@domain.com |
| Controls TLS certificate handling | true |
| Kubernetes pod affinity/anti‑affinity rules. Empty {} means pods can be scheduled anywhere. | &affinity {} |
| Simple mapping of labels > nodes. Empty {} means no node label constraints. | &nodeSelector {} |
| Allows pods to be scheduled onto tainted nodes. Empty [] means no special tolerations. | &tolerations [] |
SMTP configuration
cp-configs:
smtp:
smtpHost: smtp.gmail.com
smtpPort: "587"
smtpUsername: ""
smtpPassword: ""
smtpFromEmail: "noreplies@virtana.com"
smtpTlsInsecureSkipVerify: "false"The following table describes each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| SMTP server address | smtp.gmail.com |
| SMTP port | "587" |
| Authentication credentials for the SMTP server. | " " |
| Sender address for outgoing notification emails. | "noreplies@virtana.com" |
| "false" verifies TLS certificates | "false" |
GrowthBook configuration
growthbook:
ingress:
enabled: true
annotations:
nginx.ingress.kubernetes.io/cors-allow-origin: "https://<GROWTH_BOOK_HOSTNAME>"
appOriginName: <GROWTH_BOOK_HOSTNAME>
apiHostName: <GROWTH_BOOK_API_HOSTNAME>
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerationsThe following table describes each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| Restricts browser CORS requests to the GrowthBook UI hostname. |
|
| Hostname for the GrowthBook web UI. |
|
| Hostname for the GrowthBook API endpoint. |
|
Storage and Infrastructure Components
cp-mongodb:
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
migration:
enabled: true
persistence:
size: 50Gi
minio:
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
persistence:
size: 20Gi
redis:
persistentVolumeClaim:
existingPersistentVolumeClaim: "redis-data-controlplane-infra-redis-master-0"
strimzi-kafka-operator:
controller:
persistence:
size: 50Gi
cloud-native-postgresql-cluster:
affinity: *affinity
cp-metrics-service:
victoria-metrics-single:
rbac:
create: true
namespaced: true
server:
size: 100Gi
alerts-service:
solrdb:
enabled: true
persistent_ebs:
spec:
resources:
requests:
storage: 100Gi
solr:
enabled: false
persistence:
size: 50Gi
zookeeper:
persistence:
size: 20GiThe following table describes each field in the configuration file.
Fields | Description | Default values |
|---|---|---|
| MongoDB for control plane document storage. | 50 Gib |
| S3-compatible object storage for files and artifacts. | 20 Gib |
| Specifies the name of a pre-existing Persistent Volume Claim (PVC) that the Redis pod should use for data storage, instead of creating a new one. | "redis-data-controlplane-infra-redis-master-0" |
| Defines the storage capacity allocated to the Kafka controller's persistent volume. | 50 Gib |
| Controls pod scheduling rules that determine which Kubernetes nodes the PostgreSQL cluster pods are placed on. | *affinity |
| When set to | true |
| When set to | true |
| Time-series metrics database. Increase for long retention or high ingestion. RBAC is namespaced. | 100 Gib |
| Enables the SolrDB component. | true |
| EBS-backed Solr database for alert indexing. | 100 Gib |
| Disables the in‑chart Solr deployment. | false |
| The disk size for Solr. | 50 Gib |
| Zookeeper persistence volume size for Solr’s coordination service. | 20 Gib |
Private container registry override (optional)
Create a file named global-view-image-registry.yaml. For detailed information, see Overriding the Private Container Registry.
Deploy Global View
In this step, you apply the prepared Helm values and image registry overrides to roll out the upgraded Global View stack to your Kubernetes or OpenShift cluster. The deployment is performed in the following three phases: CRDs, infrastructure modules, and service modules. It ensures that all required custom resources, storage, messaging, and application services are created and upgraded in a controlled, dependency-aware order using the virtana-repo/virtana-global-view Helm chart.
See the detailed Global View deployment steps in Deploying Global View.
Verify the upgrade
To ensure Global View is accessible, perform the following steps:
Open your web browser and navigate to
https://<global_view_hostname>/ui. Replace<global_view_hostname>with the hostname you defined during configuration.Log in using the organizational email address and the password you created during registration.
If the UI loads and login succeeds, the upgrade is complete.