The general settings house settings typical to Kubernetes deployments, in most common scenarios these settings can be left untouched.

### General settings ###
replicaCount: 1 # By default we run only one replica. Multiple replicas are NOT supported.
nameOverride: ""
fullnameOverride: ""
serviceAccount:
  # Specifies whether a service account should be created
  create: true
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: ""
podAnnotations: {}
podSecurityContext: {}
securityContext: {}
serviceType: ClusterIP
nodeSelector: {}
tolerations: []
affinity: {}

The Image settings house the pull policy as well as container registry and repository information along with version information. It is important to update the registry and repository details here to match your own environment. Tag should also follow the version number of the tungsten dashboard you want to deploy.

### Image settings ###
image:
  registry: "" # Your container registry hostname should be entered here
  repository: tungsten-dashboard
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: "8.0.3"

The secrets section specifies details related to the usage of secrets in the helm installation, it is recommended to not change these values.

### Secrets ###
imagePullSecrets: []
crypt:
  secretName: "tungsten-dashboard-secret"
  value: ""

The clusters section allows you to predefine clusters you want the dashboard to connect to. As you define the clusters you may want to include their host details into the Network section to make sure dashboard is able to resolve the IP of your cluster.

### Clusters ### 
# You can list connected clusters to dashboard here.
# When this is enabled, dashboard configuration is read-only, and only way to modify clusters is via Helm values.
clusters: []
  # - host: "db1.example.com"
  #   namespace: "dev"
  #   tcpPort: 11999
  #   apiPort: 8090
  #   ssl: true
  #   cert: "<base64-encoded-certificate>"
  #   apiUser: "sample-user"
  #   apiPassword: "<clear-text-password>"
  #   apiSsl: true
  #   apiCert: "<base64-encoded-certificate>"
  #   hostnameValidation: true

The application configuration allows you to fine-tune the behaviour of the dashboard application. Important details are domain, path, port and browserPort fields.

Port can generally be left untouched, but browserPort should be updated to match the port of your ingress, gateway or other traffic routing solution.

### Application configuration ###
config:
  env: "production"
  version: "8.0.3"
  configPath: "/app/persistent/"
  logType: "console-edn"
  helm: true
  domain: ""
  path: ""
  port: 4090
  # internal ssl toggle (keep false for kubernetes; use ingress)
  ssl: false 
  sslPort: 4091 
  browserPort:
  clustersConnectOnStart: false
  topologyStartupDiscover: false
  topologyCleanOnExit: false
  defaultRestPort: 8090
  defaultTcpPort: 11999
  hostnameValidation: true
  restTimeout: 120000

Users allows you to predefine users available to use the dashboard itself. If you want more than one user by default, define them here.

### users ###
users:
  - role: admin
    username: default-admin-username
    password: default-admin-password
    email: "admin@admin.com"

Passwords in here are provided as clear text but they will be encrypted during installation.

The network section houses the settings to configure ingress and host alias details for the dashboard container. Please note that the ingress configuration here only deploys an ingress resource by default, if you do not use the install script you must install ingress manually for the details in this section to have effect. Notable fields for ingress are: enabled, classname and tls details.

### Network ###
ingress:
  # When true, creates dashboard ingress resource
  enabled: false 
  # You must create the IngressClass and then add it here.
  # Example of a controller: nginx see https://github.com/kubernetes/ingress-nginx for more information
  className: "" # ingressClassName ie. nginx
  # use config field's domain, path and port for ingress.
  # to fully control your setup set this to false and specify extraHosts.
  hostFromConfig: true
  annotations: {}
  # kubernetes.io/ingress.class: nginx
  # kubernetes.io/tls-acme: "true"
  extraHosts: []
  #  - host: chart-example.local
  #    paths:
  #      - path: /
  #        pathType: Prefix
  # TLS config for ingress.
  # To use this create a secret with any name and add it here.
  # The secret must contain both base64 encoded certificate and the key as base64 encoded values.
  # See https://kubernetes.io/docs/concepts/services-networking/ingress/#tls for more
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local # This value must match config.domain field
hostAliases: []
  # If you are using Tungsten node names that cannot be resolved, such as db1, db2 etc. in tungsten.ini,
  # you can associate them with their corresponding IP addresses using hostAliases
  # - ip: "10.0.0.1"
  #   hostnames:
  #   - "db1"
  # - ip: "10.0.0.2"
  #   hostnames:
  #   - "db2"
  # - ip: "10.0.0.3"
  #   hostnames:
  #   - "db3"

The resources section covers the amount of cpu and memory limits along with persistence configurations for the dashboard. If you do configure the limitations for resources please allocate enough to cover the jvm usage of the dashboard. Minimum of atleast 1 gigabyte is recommended depending on the amount of clusters you connect to and the amount of users present.

### Resources ### 
resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 100m
  #   memory: 128Mi
  # requests:
  #   cpu: 100m
  #   memory: 128Mi
# Whether to persist changes to disk or not. The dashboard writes some semi-persistent metadata such as discovered topologies of the Tungsten clusters to a file.
# If you want to persist that over pod restarts, you can enable it here.
#
# In addition, if clusters configuration is not managed declaratively, and you are using edit features within the dashboard UI, only way to persist those is enable this.
persistence:
  # enabled: true ; persistence cannot be disabled as it is required by init containers.
  size: 1Gi
  # If defined, storageClassName: <storageClass>.
  # If set to "-", storageClassName: "", which disables dynamic provisioning.
  # If empty or set to null, no storageClassName spec is
  # set, choosing the default provisioner (gp2 on AWS, standard on GKE, AWS, and OpenStack).
  storageClass: null
  # -- Selector for persistent disk
  selector: null
  # -- Annotations for volume claim
  annotations: {}