## Atlassian Jira Data Center Helm values
#
# HEADS UP!
#
# Data loss will occur if sections declared as 'REQUIRED' are not configured appropriately!
# These sections are:
# - database
# - volumes
#
# Additional details on pre-provisioning these required resources can be found here:
# https://atlassian.github.io/data-center-helm-charts/userguide/INSTALLATION/#3-configure-database
# https://atlassian.github.io/data-center-helm-charts/userguide/INSTALLATION/#5-configure-persistent-storage
#
# To manage external access to the Jira instance, an ingress resource can also be configured
# under the 'ingress' stanza. This requires a pre-provisioned ingress controller to be present.
#
# Additional details on pre-provisioning an ingress controller can be found here:
# https://atlassian.github.io/data-center-helm-charts/userguide/INSTALLATION/#4-configure-ingress
#
##

# -- The initial number of Jira pods that should be started at deployment time.
# Note that Jira requires manual configuration via the browser post deployment
# after the first pod is deployed. This configuration must be completed before
# scaling up additional pods. As such this value should always be kept as 1,
# but can be altered once manual configuration is complete.
#
replicaCount: 1

# Image configuration
#
image:
  # -- The Jira Docker image to use
  # https://hub.docker.com/r/atlassian/jira-software
  #
  repository: atlassian/jira-software

  # -- Image pull policy
  #
  pullPolicy: IfNotPresent

  # -- The docker image tag to be used - defaults to the Chart appVersion
  #
  tag: ""

# K8s ServiceAccount configuration. Give fine-grained identity and authorization
# to Pods
#
serviceAccount:
  # -- Set to 'true' if a ServiceAccount should be created, or 'false' if it
  # already exists.
  #
  create: true

  # -- The name of the ServiceAccount to be used by the pods. If not specified, but
  # the "serviceAccount.create" flag is set to 'true', then the ServiceAccount name
  # will be auto-generated, otherwise the 'default' ServiceAccount will be used.
  # https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server
  #
  name:

  # -- For Docker images hosted in private registries, define the list of image pull
  # secrets that should be utilized by the created ServiceAccount
  # https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod
  #
  imagePullSecrets: []
  # - name: secretName

  # -- Annotations to add to the ServiceAccount (if created)
  #
  annotations: {}

# REQUIRED - Database configuration
#
# Jira requires a backend database. The configuration below can be used to define the
# database to use and its connection details.
# https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#database-connectivity
#
database:
  # -- The database type that should be used. If not specified, then it will need to be
  # provided via the browser during manual configuration post deployment. Valid values
  # include:
  # - 'postgres72'
  # - 'mysql57'
  # - 'mysql8'
  # - 'oracle10g'
  # - 'mssql'
  # - 'postgresaurora96'
  # https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#databasetype
  #
  type:

  # -- The jdbc URL of the database. If not specified, then it will need to be provided
  # via the browser during manual configuration post deployment. Example URLs include:
  # - 'jdbc:postgresql://<dbhost>:5432/<dbname>'
  # - 'jdbc:mysql://<dbhost>/<dbname>'
  # - 'jdbc:sqlserver://<dbhost>:1433;databaseName=<dbname>'
  # - 'jdbc:oracle:thin:@<dbhost>:1521:<SID>'
  # https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#databaseurl
  #
  url:

  # -- The Java class name of the JDBC driver to be used. If not specified, then it will
  # need to be provided via the browser during manual configuration post deployment.
  # Valid drivers are:
  # - 'org.postgresql.Driver'
  # - 'com.mysql.jdbc.Driver'
  # - 'oracle.jdbc.OracleDriver'
  # - 'com.microsoft.sqlserver.jdbc.SQLServerDriver'
  # https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#databasedriver:
  #
  driver:

  # JDBC connection credentials
  #
  credentials:
    # -- The name of the K8s Secret that contains the database login credentials.
    # If the secret is specified, then the credentials will be automatically utilised on
    # Jira startup. If the secret is not provided, then the credentials will need to be
    # provided via the browser during manual configuration post deployment.
    #
    # Example of creating a database credentials K8s secret below:
    # 'kubectl create secret generic <secret-name> --from-literal=username=<username> \
    # --from-literal=password=<password>'
    # https://kubernetes.io/docs/concepts/configuration/secret/#opaque-secrets
    #
    secretName:

    # -- The key ('username') in the Secret used to store the database login username
    #
    usernameSecretKey: username

    # -- The key ('password') in the Secret used to store the database login password
    #
    passwordSecretKey: password

# REQUIRED - Volume configuration
#
# By default, the charts will configure the local-home and shared-home as ephemeral
# volumes i.e. 'emptyDir: {}'. This is fine for evaluation purposes but for production
# deployments this is not ideal and so local-home and shared-home should both be configured
# appropriately.
# https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#volumes
#
volumes:
  # Each pod requires its own volume for 'local-home'. This is needed for key data
  # that help define how Jira works.
  # https://confluence.atlassian.com/adminjiraserver/jira-application-home-directory-938847746.html
  #
  localHome:
    # Dynamic provisioning of local-home using the K8s Storage Classes
    #
    # https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic
    # https://atlassian.github.io/data-center-helm-charts/examples/storage/aws/LOCAL_STORAGE/
    #
    persistentVolumeClaim:
      # -- If 'true', then a 'PersistentVolume' and 'PersistentVolumeClaim' will be dynamically
      # created for each pod based on the 'StorageClassName' supplied below.
      #
      create: false

      # -- Specify the name of the 'StorageClass' that should be used for the local-home
      # volume claim.
      #
      storageClassName:

      # -- Specifies the standard K8s resource requests and/or limits for the local-home
      # volume claims.
      #
      resources:
        requests:
          storage: 1Gi

    # -- Static provisioning of local-home using K8s PVs and PVCs
    #
    # NOTE: Due to the ephemeral nature of pods this approach to provisioning volumes for
    # pods is not recommended. Dynamic provisioning described above is the prescribed
    # approach.
    #
    # When 'persistentVolumeClaim.create' is 'false', then this value can be used to define
    # a standard K8s volume that will be used for the local-home volume(s). If not defined,
    # then an 'emptyDir' volume is utilised. Having provisioned a 'PersistentVolume', specify
    # the bound 'persistentVolumeClaim.claimName' for the 'customVolume' object.
    # https://kubernetes.io/docs/concepts/storage/persistent-volumes/#static
    #
    customVolume: {}
    # persistentVolumeClaim:
    #   claimName: "<pvc>"

    # -- Specifies the path in the Jira container to which the local-home volume will be
    # mounted.
    #
    mountPath: "/var/atlassian/application-data/jira"

  # A volume for 'shared-home' is required by Jira to effectively operate in multi-node
  # environment
  # https://confluence.atlassian.com/adminjiraserver/set-up-a-jira-data-center-cluster-993929600.html
  #
  sharedHome:
    # Dynamic provisioning of shared-home using the K8s Storage Class
    #
    # https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic
    #
    persistentVolumeClaim:
      # -- If 'true', then a 'PersistentVolumeClaim' and 'PersistentVolume' will be dynamically
      # created for shared-home based on the 'StorageClassName' supplied below.
      #
      create: false

      # -- Specify the name of the 'StorageClass' that should be used for the 'shared-home'
      #volume claim.
      #
      storageClassName:

      # -- Specifies the standard K8s resource requests and/or limits for the shared-home
      # volume claims.
      #
      resources:
        requests:
          storage: 1Gi

    # -- Static provisioning of shared-home using K8s PVs and PVCs
    #
    # When 'persistentVolumeClaim.create' is 'false', then this value can be used to define
    # a standard K8s volume that will be used for the shared-home volume. If not defined,
    # then an 'emptyDir' volume is utilised. Having provisioned a 'PersistentVolume', specify
    # the bound 'persistentVolumeClaim.claimName' for the 'customVolume' object.
    # https://kubernetes.io/docs/concepts/storage/persistent-volumes/#static
    # https://atlassian.github.io/data-center-helm-charts/examples/storage/aws/SHARED_STORAGE/
    #
    customVolume: {}
    # persistentVolumeClaim:
    #   claimName: "<pvc>"

    # -- Specifies the path in the Jira container to which the shared-home volume will be
    # mounted.
    #
    mountPath: "/var/atlassian/application-data/shared-home"

    # -- Specifies the sub-directory of the shared-home volume that will be mounted in to the
    # Jira container.
    #
    subPath:

    # Modify permissions on shared-home
    #
    nfsPermissionFixer:
      # -- If 'true', this will alter the shared-home volume's root directory so that Jira
      # can write to it. This is a workaround for a K8s bug affecting NFS volumes:
      # https://github.com/kubernetes/examples/issues/260
      #
      enabled: true

      # -- The path in the K8s initContainer where the shared-home volume will be mounted
      #
      mountPath: "/shared-home"

      # -- Image repository for the permission fixer init container. Defaults to alpine
      #
      imageRepo: alpine
      # -- Image tag for the permission fixer init container. Defaults to latest
      #
      imageTag: latest

      # -- By default, the fixer will change the group ownership of the volume's root directory
      # to match the Jira container's GID (2001), and then ensures the directory is
      # group-writeable. If this is not the desired behaviour, command used can be specified
      # here.
      #
      command:

  # -- Defines additional volumes that should be applied to all Jira pods.
  # Note that this will not create any corresponding volume mounts;
  # those needs to be defined in jira.additionalVolumeMounts
  #
  additional: []

# Ingress configuration
#
# To make the Atlassian product available from outside the K8s cluster an Ingress
# Controller should be pre-provisioned. With this in place the configuration below
# can be used to configure an appropriate Ingress Resource.
# https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#ingress
#
ingress:
  # -- Set to 'true' if an Ingress Resource should be created. This depends on a
  # pre-provisioned Ingress Controller being available.
  #
  create: false

  # -- The class name used by the ingress controller if it's being used.
  #
  # Please follow documentation of your ingress controller. If the cluster
  # contains multiple ingress controllers, this setting allows you to control
  # which of them is used for Atlassian application traffic.
  #
  className: "nginx"

  # -- Set to 'true' if the Ingress Resource is to use the K8s 'ingress-nginx'
  # controller.
  # https://kubernetes.github.io/ingress-nginx/
  #
  # This will populate the Ingress Resource with annotations that are specific to
  # the K8s ingress-nginx controller. Set to 'false' if a different controller is
  # to be used, in which case the appropriate annotations for that controller must
  # be specified below under 'ingress.annotations'.
  #
  nginx: true

  # -- The max body size to allow. Requests exceeding this size will result
  # in an HTTP 413 error being returned to the client.
  #
  maxBodySize: 250m

  # -- Defines a timeout for establishing a connection with a proxied server. It should
  # be noted that this timeout cannot usually exceed 75 seconds.
  #
  proxyConnectTimeout: 60

  # -- Defines a timeout for reading a response from the proxied server. The timeout is
  # set only between two successive read operations, not for the transmission of the
  # whole response. If the proxied server does not transmit anything within this time,
  # the connection is closed.
  #
  proxyReadTimeout: 60

  # -- Sets a timeout for transmitting a request to the proxied server. The timeout is set
  # only between two successive write operations, not for the transmission of the whole
  # request. If the proxied server does not receive anything within this time, the
  # connection is closed.
  #
  proxySendTimeout: 60

  # -- The fully-qualified hostname (FQDN) of the Ingress Resource. Traffic coming in on
  # this hostname will be routed by the Ingress Resource to the appropriate backend
  # Service.
  #
  host:

  # -- The base path for the Ingress Resource. For example '/jira'. Based on a
  # 'ingress.host' value of 'company.k8s.com' this would result in a URL of
  # 'company.k8s.com/jira'. Default value is 'jira.service.contextPath'
  #
  path:

  # -- The custom annotations that should be applied to the Ingress Resource
  # when NOT using the K8s ingress-nginx controller.
  #
  annotations: {}

  # -- Set to 'true' if browser communication with the application should be TLS
  # (HTTPS) enforced.
  #
  https: true

  # -- The name of the K8s Secret that contains the TLS private key and corresponding
  # certificate. When utilised, TLS termination occurs at the ingress point where
  # traffic to the Service, and it's Pods is in plaintext.
  #
  # Usage is optional and depends on your use case. The Ingress Controller itself
  # can also be configured with a TLS secret for all Ingress Resources.
  # https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets
  # https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
  #
  tlsSecretName:

# Jira configuration
#
jira:
  # K8s Service configuration
  #
  service:
    # -- The port on which the Jira K8s Service will listen
    #
    port: 80

    # -- The type of K8s service to use for Jira
    #
    type: ClusterIP

    # -- Use specific loadBalancerIP. Only applies to service type LoadBalancer.
    #
    loadBalancerIP:

    # -- The Tomcat context path that Jira will use. The ATL_TOMCAT_CONTEXTPATH
    # will be set automatically.
    #
    contextPath:

    # -- Additional annotations to apply to the Service
    #
    annotations: {}

  # Standard K8s field that holds pod-level security attributes and common container settings.
  # https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
  # Do not populate when deploying to OpenShift, unless anyuid policy is attached to a service account.
  #

  # -- Whether to apply security context to pod.
  #
  securityContextEnabled: true

  securityContext:
    # -- The GID used by the Jira docker image
    # GID will default to 2001 if not supplied and securityContextEnabled is set to true.
    # This is intended to ensure that the shared-home volume is group-writeable by the GID used by the Jira container.
    # However, this doesn't appear to work for NFS volumes due to a K8s bug: https://github.com/kubernetes/examples/issues/260
    #
    fsGroup: 2001

  # -- Standard K8s field that holds security configurations that will be applied to a container.
  # https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
  #
  containerSecurityContext: {}

  # -- Boolean to define whether to set local home directory permissions on startup
  # of Jira container. Set to 'false' to disable this behaviour.
  #
  setPermissions: true

  # Port definitions
  #
  ports:
    # -- The port on which the Jira container listens for HTTP traffic
    #
    http: 8080

    # -- Ehcache port
    #
    ehcache: 40001

    # -- Ehcache object port
    #
    ehcacheobject: 40011

  # Confirm that Jira is available with a ReadinessProbe
  # https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes
  #
  readinessProbe:
    # -- The initial delay (in seconds) for the Jira container readiness probe,
    # after which the probe will start running.
    #
    initialDelaySeconds: 10

    # -- How often (in seconds) the Jira container readiness probe will run
    #
    periodSeconds: 5

    # -- The number of consecutive failures of the Jira container readiness probe
    # before the pod fails readiness checks.
    #
    failureThreshold: 1

  # Confirm that Jira is up and running with a StartupProbe
  # https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes
  #
  startupProbe:
    # -- How often (in seconds) the Jira container startup probe will run
    #
    periodSeconds: 5

    # -- The number of consecutive failures of the Jira container startup probe
    # before the pod fails startup checks.
    #
    failureThreshold: 120

  # Ensure that pods are working correctly with a LivenessProbe
  # https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request
  #
  livenessProbe:
    # -- Whether to apply the livenessProbe check to pod.
    #

    enabled: true

    # -- How often (in seconds) the Jira container liveness probe will run
    #
    periodSeconds: 5

    # -- The number of consecutive failures of the Jira container liveness probe
    # before the pod fails liveness checks.
    #
    failureThreshold: 1

  # Jira log configuration
  #
  accessLog:
    # -- The path within the Jira container where the local-home volume should be
    # mounted in order to capture access logs.
    #
    mountPath: "/opt/atlassian/jira/logs"

    # -- The subdirectory within the local-home volume where access logs should be
    # stored.
    #
    localHomeSubPath: "log"

  # Data Center clustering
  #
  clustering:
    # -- Set to 'true' if Data Center clustering should be enabled
    # This will automatically configure cluster peer discovery between cluster nodes.
    #
    enabled: false

  shutdown:
    # -- The termination grace period for pods during shutdown. This
    # should be set to the internal grace period, plus a small buffer
    # to allow the JVM to fully terminate.
    #
    terminationGracePeriodSeconds: 30

    # -- By default pods will be stopped via a [preStop hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/),
    # using a script supplied by the Docker image. If any other
    # shutdown behaviour is needed it can be achieved by overriding
    # this value. Note that the shutdown command needs to wait for the
    # application shutdown completely before exiting; see [the default
    # command](https://bitbucket.org/atlassian-docker/docker-atlassian-jira/src/master/shutdown-wait.sh)
    # for details.
    #
    command: "/shutdown-wait.sh"

  # Pod resource requests
  #
  resources:
    # JVM Memory / Heap Size definitions. The values below are based on the
    # defaults defined for the Jira docker container.
    # https://bitbucket.org/atlassian-docker/docker-atlassian-jira/src/master/#markdown-header-memory-heap-size
    #
    jvm:
      # -- The maximum amount of heap memory that will be used by the Jira JVM
      #
      maxHeap: "768m"

      # -- The minimum amount of heap memory that will be used by the Jira JVM
      #
      minHeap: "384m"

      # -- The memory reserved for the Jira JVM code cache
      #
      reservedCodeCache: "512m"

    # Specifies the standard K8s resource requests and/or limits for the Jira
    # container. It is important that if the memory resources are specified here,
    # they must allow for the size of the Jira JVM. That means the maximum heap
    # size, the reserved code cache size, plus other JVM overheads, must be
    # accommodated. Allowing for (maxHeap+codeCache)*1.5 would be an example.
    #
    container:
      requests:
        # -- Initial CPU request by Jira pod
        #
        cpu: "2"

        # -- Initial Memory request by Jira pod
        #
        memory: "2G"
      #  limits:
      #    cpu: "2"
      #    memory: "2G"

  # -- The Docker entrypoint.py generates application configuration on
  # first start; not all of these files are regenerated on subsequent starts.
  # By default, dbconfig.xml is generated only once. Set `forceConfigUpdate` to true
  # to change this behaviour.
  #
  forceConfigUpdate: false
  # Specifies a list of additional arguments that can be passed to the Jira JVM, e.g.
  # system properties.
  #
  additionalJvmArgs: []

  # -- Specifies a list of additional Java libraries that should be added to the
  # Jira container. Each item in the list should specify the name of the volume
  # that contains the library, as well as the name of the library file within that
  # volume's root directory. Optionally, a subDirectory field can be included to
  # specify which directory in the volume contains the library file. Additional details:
  # https://atlassian.github.io/data-center-helm-charts/examples/external_libraries/EXTERNAL_LIBS/
  #
  additionalLibraries: []
  #  - volumeName:
  #    subDirectory:
  #    fileName:

  # -- Specifies a list of additional Jira plugins that should be added to the
  # Jira container. Note plugins installed via this method will appear as
  # bundled plugins rather than user plugins. These should be specified in the same
  # manner as the 'additionalLibraries' property. Additional details:
  # https://atlassian.github.io/data-center-helm-charts/examples/external_libraries/EXTERNAL_LIBS/
  #
  # NOTE: only .jar files can be loaded using this approach. OBR's can be extracted
  # (unzipped) to access the associated .jar
  #
  # An alternative to this method is to install the plugins via "Manage Apps" in the
  # product system administration UI.
  #
  additionalBundledPlugins: []
  #  - volumeName:
  #    subDirectory:
  #    fileName:

  # -- Defines any additional volumes mounts for the Jira container. These
  # can refer to existing volumes, or new volumes can be defined via
  # 'volumes.additional'.
  #
  additionalVolumeMounts: []

  # -- Defines any additional environment variables to be passed to the Jira
  # container. See https://hub.docker.com/r/atlassian/jira-software for
  # supported variables.
  #
  additionalEnvironmentVariables: []

  # -- Defines any additional ports for the Jira container.
  #
  additionalPorts: []
  #  - name: jmx
  #    containerPort: 5555
  #    protocol: TCP

  # -- Defines additional volumeClaimTemplates that should be applied to the Jira pod.
  # Note that this will not create any corresponding volume mounts;
  # those needs to be defined in jira.additionalVolumeMounts
  #
  additionalVolumeClaimTemplates: []
  #  - name: myadditionalvolumeclaim
  #    storageClassName:
  #    resources:
  #      requests:
  #        storage: 1Gi

  # -- Defines topology spread constraints for Jira pods. See details:
  # https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/
  #
  topologySpreadConstraints: []
  # - maxSkew: 1
  #   topologyKey: kubernetes.io/hostname
  #   whenUnsatisfiable: ScheduleAnyway
  #   labelSelector:
  #     matchLabels:

# Fluentd configuration
#
# Jira log collection and aggregation can be enabled using Fluentd. This config
# assumes an existing ELK stack has been stood up and is available.
# https://www.fluentd.org/
#
fluentd:
  # -- Set to 'true' if the Fluentd sidecar (DaemonSet) should be added to each pod
  #
  enabled: false

  # -- The Fluentd sidecar image repository
  #
  imageRepo: fluent/fluentd-kubernetes-daemonset
  # -- The Fluentd sidecar image tag
  #
  imageTag: v1.11.5-debian-elasticsearch7-1.2

  # -- The command used to start Fluentd. If not supplied the default command
  # will be used: "fluentd -c /fluentd/etc/fluent.conf -v"
  #
  # Note: The custom command can be free-form, however pay particular attention to
  # the process that should ultimately be left running in the container. This process
  # should be invoked with 'exec' so that signals are appropriately propagated to it,
  # for instance SIGTERM. An example of how such a command may look is:
  # "<command 1> && <command 2> && exec <primary command>"
  command:

  # -- Set to 'true' if a custom config (see 'configmap-fluentd.yaml' for default)
  # should be used for Fluentd. If enabled this config must be supplied via the
  # 'fluentdCustomConfig' property below.
  #
  customConfigFile: false

  # -- Custom fluent.conf file
  #
  fluentdCustomConfig: {}
  # fluent.conf: |
  # <source>
  #   @type tail
  #   <parse>
  #   @type multiline
  #   format_firstline /\d{4}-\d{1,2}-\d{1,2}/
  #   </parse>
  #   path /opt/atlassian/jira/logs/access_log.*
  #   pos_file /tmp/jiralog.pos
  #   tag jira-access-logs
  # </source>

  # -- The port on which the Fluentd sidecar will listen
  #
  httpPort: 9880

  # Elasticsearch config based on your ELK stack
  #
  elasticsearch:
    # -- Set to 'true' if Fluentd should send all log events to an Elasticsearch service.
    #
    enabled: true

    # -- The hostname of the Elasticsearch service that Fluentd should send logs to.
    #
    hostname: elasticsearch

    # -- The prefix of the Elasticsearch index name that will be used
    #
    indexNamePrefix: jira

  # -- Specify custom volumes to be added to Fluentd container (e.g. more log sources)
  #
  extraVolumes: []
  # - name: local-home
  #   mountPath: /opt/atlassian/jira/logs
  #   subPath: log
  #   readOnly: true

# -- Custom annotations that will be applied to all Jira pods
#
podAnnotations: {}
#  name: <value>

# -- Custom labels that will be applied to all Jira pods
#
podLabels: {}
#  name: <value>

# -- Standard K8s node-selectors that will be applied to all Jira pods
#
nodeSelector: {}
#  name: <value>

# -- Standard K8s tolerations that will be applied to all Jira pods
#
tolerations: []
# - effect: <name>
#   operator: <operator>
#   key: <key>

# -- Standard K8s affinities that will be applied to all Jira pods
#
affinity: {}
#  name: <value>

# -- Standard K8s schedulerName that will be applied to all Jira pods.
# Check Kubernetes documentation on how to configure multiple schedulers:
# https://kubernetes.io/docs/tasks/extend-kubernetes/configure-multiple-schedulers/#specify-schedulers-for-pods
#
schedulerName:

# -- Additional container definitions that will be added to all Jira pods
#
additionalContainers: []
#  - name: <name>
#    image: <image>:<tag>

# -- Additional initContainer definitions that will be added to all Jira pods
#
additionalInitContainers: []
#  - name: <name>
#    image: <image>:<tag>

# -- Additional labels that should be applied to all resources
#
additionalLabels: {}
#  name: <value>

# -- Additional existing ConfigMaps and Secrets not managed by Helm that should be
# mounted into service container. Configuration details below (camelCase is important!):
# 'name'      - References existing ConfigMap or secret name.
# 'type'      - 'configMap' or 'secret'
# 'key'       - The file name.
# 'mountPath' - The destination directory in a container.
# VolumeMount and Volumes are added with this name and index position, for example;
# custom-config-0, keystore-2
#
additionalFiles: []
#  - name: custom-config
#    type: configMap
#    key: log4j.properties
#    mountPath:  /var/atlassian
#  - name: custom-config
#    type: configMap
#    key: web.xml
#    mountPath: /var/atlassian
#  - name: keystore
#    type: secret
#    key: keystore.jks
#    mountPath: /var/ssl