Global View Upgrade (2026.9.1)

The following table describes the fields in the global block of global-view-values.yaml:

The global.dockerRegistryCredentials section in global-view-values.yaml takes one of two forms, depending on how your cluster reaches the container images.

For a private registry in an air-gapped environment, specify a single registry server:

  dockerRegistryCredentials:
    DOCKER_SERVER: "https://index.docker.io/v2/"
    DOCKER_USERNAME: "username"
    DOCKER_PASSWORD: "password"

For direct access to Docker Hub, specify one or more registry servers:

  dockerRegistryCredentials:
    DOCKER_USERNAME: "username"
    DOCKER_PASSWORD: "password"
    DOCKER_SERVERS:
      - "https://index.docker.io/v2/"
      - "https://dhi.io/"

The following table describes the Docker registry credential fields:

This section describes the SMTP, GrowthBook, and infrastructure blocks in global-view-values.yaml. Each block includes a YAML sample and a table that describes its fields.

The SMTP configuration block sets the mail server that Global View uses to send notification emails. The block sits under cp-configs in global-view-values.yaml:

cp-configs:
  smtp:
    smtpHost: smtp.gmail.com
    smtpPort: "587"
    smtpUsername: ""
    smtpPassword: ""
    smtpFromEmail: "noreplies@virtana.com"
    smtpTlsInsecureSkipVerify: "false"

The following table describes the SMTP configuration fields:

The GrowthBook configuration block sets the ingress, hostnames, and scheduling rules for the GrowthBook feature-flag service. The block appears in global-view-values.yaml as follows:

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: *tolerations

The following table describes the GrowthBook configuration fields:

The storage and infrastructure blocks configure MongoDB, object storage, Redis, Kafka, PostgreSQL, and metrics. SeaweedFS replaces MinIO as the object storage backend, so the values file has no minio block. These blocks appear in global-view-values.yaml as follows:

cp-mongodb:
  affinity: *affinity
  nodeSelector: *nodeSelector
  tolerations: *tolerations
  migration:
    enabled: false
  persistence:
    size: 50Gi

seaweedfs:
  allInOne:
    data:
      type: persistentVolumeClaim
      size: 20Gi
      storageClass: *defaultStorageClass
    # Configure scheduling settings explicitly for SeaweedFS.
    # Global affinity, nodeSelector, and tolerations cannot be reused because
    # the SeaweedFS chart expects these values as templated strings instead of
    # native Kubernetes objects.
    nodeSelector: ""
    affinity: ""
    tolerations: ""

redis:
  persistentVolumeClaim:
    size: 50Gi
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      cpu: 500m
      memory: 256Mi

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:
      persistentVolume:
        storageClassName: *defaultStorageClass
        size: 16Gi

The following table describes the storage and infrastructure fields:

The alerts-service block configures the alerts database and SolrCloud. Two values in this block depend on the version that you upgrade from:

If you upgrade from 2026.6.1, set both values to false, because your SolrCloud data is already migrated. If you upgrade from 2026.4.1, set both values to true so that the SolrCloud migration runs during the upgrade.

For an upgrade from 2026.6.1, the alerts-service block looks like this:

alerts-service:
  solrdb:
    enabled: false
    persistent_ebs:
      spec:
        resources:
          requests:
            storage: 100Gi
  solr:
    enabled: false
    migration:
      enabled: false
      storageSize: "50Gi"
      resources:
        requests:
          cpu: 100m
          memory: 1Gi
        limits:
          cpu: 500m
          memory: 1Gi
    persistence:
      size: 50Gi
    zookeeper:
      persistence:
        size: 20Gi

For an upgrade from 2026.4.1, the alerts-service block looks like this:

alerts-service:
  solrdb:
    enabled: false
    persistent_ebs:
      spec:
        resources:
          requests:
            storage: 100Gi
  solr:
    enabled: true
    migration:
      enabled: true
      storageSize: "50Gi"
      resources:
        requests:
          cpu: 100m
          memory: 1Gi
        limits:
          cpu: 500m
          memory: 1Gi
    persistence:
      size: 50Gi
    zookeeper:
      persistence:
        size: 20Gi

The following table describes the other fields in the alerts-service block. For the full list of SolrCloud migration fields, see Configure the SolrCloud migration.

This section describes two optional configurations. If you pull container images from your own registry, create a private container registry override file. If you deploy Global View on an OpenShift cluster, set the OpenShift security contexts.

A private container registry override is needed only when you want to use your own container image registry instead of Virtana's official Docker registry. To use your own registry, create a file named global-view-image-registry.yaml, and replace every occurrence of <REGISTRY_NAME> with the name of your registry:

global:
  ## Replace all occurrences of <REGISTRY_NAME> in this file with your custom image registry
  image_registry: <REGISTRY_NAME>     ## For Virtana images
  imageRegistry: <REGISTRY_NAME>      ## For open source images

growthbook:
  image:
    repository: <REGISTRY_NAME>/growthbook

redis:
  image:
    repository: <REGISTRY_NAME>/redis

cloudnative-pg:
  image:
    repository: <REGISTRY_NAME>/cloudnative-pg

cloud-native-postgresql-cluster:
  image:
    registry: <REGISTRY_NAME>

strimzi-kafka-operator:
  defaultImageRegistry: <REGISTRY_NAME>

seaweedfs:
  image:
    registry: <REGISTRY_NAME>

cp-mongodb:
  image:
    registry: <REGISTRY_NAME>

cp-metrics-service:
  victoria-metrics-single:
    server:
      image:
        repository: <REGISTRY_NAME>/victoria-metrics

alerts-service:
  solr:
    image:
      registry: <REGISTRY_NAME>
    migration:
      image:
        registry: <REGISTRY_NAME>
    zookeeper:
      image:
        registry: <REGISTRY_NAME>

infra-crds:
  kafka:
    apiConversion:
      image:
        registry: <REGISTRY_NAME>

When you use a private container registry, add -f global-view-image-registry.yaml \ to each of the helm upgrade --install commands in ???.

To deploy Global View on an OpenShift Kubernetes cluster, you must set the security contexts correctly. On OpenShift, the IDs that you set for runAsUser, runAsGroup, and fsGroup must fall within the range that the target OpenShift cluster allows.

Add the following values to global-view-values.yaml, and replace <user_id>, <group_id>, and <fsgroup_id> with values that your OpenShift cluster allows:

redis:
  securityContext:
    runAsUser: <user_id>
    runAsGroup: <group_id>
    fsGroup: <fsgroup_id>

strimzi-kafka-operator:
  podSecurityContext:
    fsGroup: <fsgroup_id>

  securityContext:
    runAsUser: <user_id>
    runAsGroup: <group_id>

cp-mongodb:
  securityContext:
    runAsUser: <user_id>
    runAsGroup: <group_id>
  podSecurityContext:
    fsGroup: <fsgroup_id>

cloudnative-pg:
  containerSecurityContext:
    runAsUser: <user_id>
    runAsGroup: <group_id>

  podSecurityContext:
    fsGroup: <fsgroup_id>

alerts-service:
  solr:
    securityContext:
      runAsUser: <user_id>
      runAsGroup: <group_id>
    podSecurityContext:
      fsGroup: <fsgroup_id>

    zookeeper:
      securityContext:
        runAsUser: <user_id>
        runAsGroup: <group_id>
      podSecurityContext:
        fsGroup: <fsgroup_id>

    # Add this if you are running solr migration
    migration:
      securityContext:
        runAsUser: <user_id>
        runAsGroup: <group_id>
      podSecurityContext:
        fsGroup: <fsgroup_id>

infra-crds:
  kafka:
    apiConversion:
      securityContext:
        runAsUser:  <user_id>
        runAsGroup: <group_id>
      podSecurityContext:
        fsGroup: <fsgroup_id>

Before you deploy, update your local Helm repository index and find the latest version of the virtana-repo/virtana-global-view chart. Use this version in place of <LATEST_VERSION> in the commands in this section:

# Check latest version of virtana-repo/virtana-global-view
helm repo update
helm search repo virtana-repo/virtana-global-view

Deploy the controlplane-crds Helm release first. This release installs the Global View custom resource definitions (CRDs) and patches the Strimzi Kafka CRDs for version 1.2 of the Strimzi Kafka operator.

You can deploy the release with the Helm CLI, Argo CD, or Terraform. Use the section for the tool that you use.

helm upgrade --install controlplane-crds virtana-repo/virtana-global-view \
  --namespace controlplane --create-namespace \
  --set tags.crds=true -f global-view-values.yaml \
  --version <LATEST_VERSION> \
  --server-side=true --force-conflicts

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: virtana-cp-crds
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    server: "https://kubernetes.default.svc"
    namespace: controlplane
  source:
    chart: virtana-global-view
    repoURL: "https://virtana.gitlab.io/helm-charts/"
    targetRevision: <LATEST_VERSION> # Provide latest version
    helm:
      releaseName: controlplane-crds
      parameters:
        - name: "tags.crds"
          value: "true"
      values: |
        <contents of global-view-values.yaml>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
    - ServerSideApply=true

resource "helm_release" "cp-crds" {
  create_namespace = true
  chart            = "virtana-global-view"
  name             = "controlplane-crds"
  namespace        = "controlplane"
  repository       = "https://virtana.gitlab.io/helm-charts"
  version          = var.helm_version
  timeout          = 1200
  wait             = true
  server_side_apply = true
  force_conflicts   = true
  values = [
    templatefile("${path.module}/../values/controlplane-values.yaml", {
      storage_class             = var.storageclass
      docker_password           = var.docker_password
      docker_username           = var.docker_username
      keycloak_hostname         = var.keycloak_hostname
      keycloak_password         = var.keycloak_password
      keycloak_username         = var.keycloak_username
      global_view_hostname      = var.global_view_hostname
      tenant_name               = var.tenant_name
      user_first_name           = var.user_first_name
      user_last_name            = var.user_last_name
      user_email                = var.user_email
      smtp_from_mail            = var.smtp_from_mail
      smtp_password             = var.smtp_password
      smtp_port                 = var.smtp_port
      smtp_server               = var.smtp_server
      smtp_to_mail              = var.smtp_to_mail
      smtp_username             = var.smtp_username
      growthbook_hostname       = var.growthbook_hostname
      growthbook_api_hostname   = var.growthbook_api_hostname
    })
  ]

  set {
    name  = "tags.crds"
    value = "true"
  }
}

Deploy the controlplane-infra Helm release after the controlplane-crds release finishes. This release deploys the infrastructure modules, including the latest version of the Strimzi Kafka operator.

You can deploy the release with the Helm CLI, Argo CD, or Terraform. Use the section for the tool that you use.

helm upgrade --install controlplane-infra virtana-repo/virtana-global-view \
  --namespace controlplane --create-namespace \
  --set tags.infra=true -f global-view-values.yaml \
  --version <LATEST_VERSION> \
  --server-side=true --force-conflicts

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: virtana-cp-infra
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    server: "https://kubernetes.default.svc"
    namespace: controlplane
  source:
    chart: virtana-global-view
    repoURL: "https://virtana.gitlab.io/helm-charts/"
    targetRevision: <LATEST_VERSION> # Provide latest version
    helm:
      releaseName: controlplane-infra
      parameters:
        - name: "tags.infra"
          value: "true"
      values: |
        <contents of global-view-values.yaml>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
    - ServerSideApply=true

resource "helm_release" "cp-infra" {
  create_namespace = true
  chart            = "virtana-global-view"
  name             = "controlplane-infra"
  namespace        = "controlplane"
  repository       = "https://virtana.gitlab.io/helm-charts"
  version          = var.helm_version
  timeout          = 1200
  wait             = true
  server_side_apply = true
  force_conflicts   = true
  values = [
    templatefile("${path.module}/../values/controlplane-values.yaml", {
      storage_class             = var.storageclass
      docker_password           = var.docker_password
      docker_username           = var.docker_username
      keycloak_hostname         = var.keycloak_hostname
      keycloak_password         = var.keycloak_password
      keycloak_username         = var.keycloak_username
      global_view_hostname      = var.global_view_hostname
      tenant_name               = var.tenant_name
      user_first_name           = var.user_first_name
      user_last_name            = var.user_last_name
      user_email                = var.user_email
      smtp_from_mail            = var.smtp_from_mail
      smtp_password             = var.smtp_password
      smtp_port                 = var.smtp_port
      smtp_server               = var.smtp_server
      smtp_to_mail              = var.smtp_to_mail
      smtp_username             = var.smtp_username
      growthbook_hostname       = var.growthbook_hostname
      growthbook_api_hostname   = var.growthbook_api_hostname
    })
  ]

  set {
    name  = "tags.infra"
    value = "true"
  }
}

Deploy the controlplane-service Helm release last. This release deploys the Global View service modules. The command sets a timeout of 1 hour (--timeout 1h). If you upgrade from version 2026.4.1, the SolrCloud migration runs during this release, and the 1-hour timeout gives the migration enough time to finish.

You can deploy the release with the Helm CLI, Argo CD, or Terraform. Use the section for the tool that you use.

helm upgrade --install controlplane-service virtana-repo/virtana-global-view \
  --namespace controlplane --create-namespace \
  --set tags.service=true -f global-view-values.yaml \
  --version <LATEST_VERSION> --timeout 1h

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: virtana-cp-service
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    server: "https://kubernetes.default.svc"
    namespace: controlplane
  source:
    chart: virtana-global-view
    repoURL: "https://virtana.gitlab.io/helm-charts/"
    targetRevision: <LATEST_VERSION> # Provide latest version
    helm:
      releaseName: controlplane-service
      parameters:
        - name: "tags.service"
          value: "true"
      values: |
        <contents of global-view-values.yaml>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

resource "helm_release" "cp-service" {
  create_namespace = true
  chart            = "virtana-global-view"
  name             = "controlplane-service"
  namespace        = "controlplane"
  repository       = "https://virtana.gitlab.io/helm-charts"
  version          = var.helm_version
  timeout          = 3600
  wait             = true
  values = [
    templatefile("${path.module}/../values/controlplane-values.yaml", {
      storage_class             = var.storageclass
      docker_password           = var.docker_password
      docker_username           = var.docker_username
      keycloak_hostname         = var.keycloak_hostname
      keycloak_password         = var.keycloak_password
      keycloak_username         = var.keycloak_username
      global_view_hostname      = var.global_view_hostname
      tenant_name               = var.tenant_name
      user_first_name           = var.user_first_name
      user_last_name            = var.user_last_name
      user_email                = var.user_email
      smtp_from_mail            = var.smtp_from_mail
      smtp_password             = var.smtp_password
      smtp_port                 = var.smtp_port
      smtp_server               = var.smtp_server
      smtp_to_mail              = var.smtp_to_mail
      smtp_username             = var.smtp_username
      growthbook_hostname       = var.growthbook_hostname
      growthbook_api_hostname   = var.growthbook_api_hostname
    })
  ]

  set {
    name  = "tags.service"
    value = "true"
  }
}

In rare cases, the deployment of the controlplane-infra Helm release fails after you upgrade the controlplane-crds Helm release. The failure is intermittent.

Version 2026.9.1 upgrades the Strimzi Kafka operator to version 1.2. During the controlplane-crds installation, Helm patches the Strimzi Kafka CRDs and custom resources. Helm might keep cached information about the CRDs and custom resources, and this cached information can cause the controlplane-infra deployment to fail.

When this issue occurs, the controlplane-infra deployment returns an error like the following:

level=WARN msg="upgrade failed" name=controlplane-infra error="server-side apply failed for object controlplane/controlplane-infra kafka.strimzi.io/v1, Kind=Kafka: request to convert CR to an invalid group/version: kafka.strimzi.io/v1beta2"
Error: UPGRADE FAILED: server-side apply failed for object controlplane/controlplane-infra kafka.strimzi.io/v1, Kind=Kafka: request to convert CR to an invalid group/version: kafka.strimzi.io/v1beta2

To resolve this issue, complete the following steps:

Redeploying the two releases in this order should resolve the issue, and the controlplane-infra release then deploys successfully. For the deployment commands, see Deploy custom resource definitions and Deploy infrastructure modules.

The Strimzi Kafka operator can stay in the CrashLoopBackOff state after you install the controlplane-crds Helm release. This behavior is expected.

The controlplane-crds installation patches and upgrades the Kafka CRDs to the latest version, and the Strimzi Kafka operator restarts after that. The operator still runs the previous version, so it keeps crashing.

To continue, deploy the controlplane-infra Helm release. This release deploys the latest version of the Strimzi Kafka operator, and the operator then starts successfully.