Global View upgrade (2026.6.1)

In version 2026.6.1, SolrCloud migration is enabled by default. The migration moves your existing Solr and ZooKeeper data to new SolrCloud pods, using a dedicated persistent volume claim (PVC) as temporary storage. Alerts data is unavailable in the Global View UI until the migration finishes.

The migration can also resize your Solr and ZooKeeper PVCs. Confirm that your storage class allows resizing before you start.

#!/bin/bash

OUTPUT_FILE="solr_pvc_usage.csv"
NAMESPACE="controlplane"

echo "Pod,Filesystem,Size,Used,Available,UsePercent" > "$OUTPUT_FILE"

# Solr pods
for pod in solrcloud-solr-0 solrcloud-solr-1 solrcloud-solr-2
do
    kubectl -n "$NAMESPACE" exec "$pod" -- df -h /bitnami/solr 2>/dev/null | \
    awk -v pod="$pod" 'NR==2 {print pod "," $1 "," $2 "," $3 "," $4 "," $5}' \
    >> "$OUTPUT_FILE"
done

# Zookeeper pods
for pod in solrcloud-zookeeper-0 solrcloud-zookeeper-1 solrcloud-zookeeper-2
do
    kubectl -n "$NAMESPACE" exec "$pod" -- df -h /bitnami/zookeeper 2>/dev/null | \
    awk -v pod="$pod" 'NR==2 {print pod "," $1 "," $2 "," $3 "," $4 "," $5}' \
    >> "$OUTPUT_FILE"
done

echo "Results written to $OUTPUT_FILE"

alerts-service:
  solr:
    migration:
      enabled: true
      storageSize: "100Gi"
      pvcResizeThreshold: 45
      resources:
        requests:
          cpu: 100m
          memory: 1Gi
        limits:
          cpu: 500m
          memory: 1Gi

Starting with version 2026.6.1, Global View uses SeaweedFS as the object storage backend instead of MinIO. Existing MinIO data migrates automatically during the upgrade.

Remove all MinIO configuration from your global-view-values.yaml file before you upgrade. New installations need no MinIO deployment or configuration changes.

SeaweedFS configuration is optional. If you don't provide any SeaweedFS configuration, Global View deploys SeaweedFS with its default settings. To customize SeaweedFS, add the following values to global-view-values.yaml:

seaweedfs:
  image:
    registry: <REGISTRY_NAME>

  allInOne:
    data:
      type: persistentVolumeClaim
      size: 20Gi
      storageClass: *defaultStorageClass

    nodeSelector: *nodeSelector
    affinity: *affinity
    tolerations: *tolerations

For the Victoria Metrics component, the storageClass parameter is renamed to storageClassName in global-view-values.yaml. Update this parameter name in your existing global-view-values.yaml file before you upgrade. The sample values in this topic use the new name.

In 2026.6.1, VirtanAI (the Copilot chatbot) uses a provider-based configuration model that supports OpenAI, Gemini, and LiteLLM. This model replaces the single OPENAI_API_KEY variable used in earlier releases.

virtana-ai:
  enabled: true
  env:
    VIRTANA_AI_MODEL_PROVIDER: ""   

cp-configs:
  virtana_ai:
    virtana_ai_api_key: ""            
    virtana_ai_inference_endpoint: "" 

VIRTANA_AI_MODEL_PROVIDER=''
VIRTANA_AI_API_KEY=''
VIRTANA_AI_INFERENCE_ENDPOINT=''

The SMTP configuration block sets the mail server that Global View uses to send notification emails. Add the following block 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. Add the following block to global-view-values.yaml:

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 block configures MongoDB, object storage, Redis, Kafka, PostgreSQL, metrics, and alerts. In 2026.6.1, SeaweedFS replaces MinIO as the object storage backend, so the minio block is removed. Add the following block to global-view-values.yaml:

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

seaweedfs:
  image:
    registry: <REGISTRY_NAME>
  allInOne:
    data:
      type: persistentVolumeClaim
      size: 20Gi
      storageClass: *defaultStorageClass
    nodeSelector: *nodeSelector
    affinity: *affinity
    tolerations: *tolerations

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: 20Gi

The following table describes the storage and infrastructure fields:

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/"

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

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

To deploy Global View on an OpenShift Kubernetes cluster, you must set the security contexts correctly. On OpenShift, the IDs 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>

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