## Atlassian Bamboo Data Center Helm values
#
# HEADS UP!
#
# Release 1.0.0 of this chart only support FULL unattended setups.
#
# All setup data (denoted with 'UNATTENDED-SETUP') required for configuring Bamboo including
# sections declared as 'REQUIRED' must be supplied up-front as part of this file.
# The property 'bamboo.unattendedSetup' is set, by default, to 'true'.
#
# As a result, post helm install of this chart, there is no manual setup required for Bamboo.
#
# 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 Bamboo 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 Bamboo pods that should be started at deployment time.
# Note that Bamboo requires manual configuration via the browser post deployment
# after the first pod is deployed.
#
# At present Bamboo Data Center utilizes an `active-passive` clustering model.
# This architecture is not ideal where K8s deployments are concerned. As such
# a Bamboo server cluster comprising only `1` pod is the recommended topology
# for now. For more detail see:
# https://atlassian.github.io/data-center-helm-charts/troubleshooting/LIMITATIONS#cluster-size
#
replicaCount: 1

# Image configuration
#
image:
  # -- The Bamboo Docker image to use
  # https://hub.docker.com/r/atlassian/bamboo-server
  #
  repository: atlassian/bamboo

  # -- 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
#
# Bamboo 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:
  # - 'postgresql'
  # - 'mysql'
  # - 'oracle12c'
  # - 'mssql'
  # 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:

  # 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
    # Bamboo 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 Bamboo works.
  # https://confluence.atlassian.com/bamboo/installing-bamboo-data-center-1063170560.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: true

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

      # -- 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 Bamboo container to which the local-home volume will be
    # mounted.
    #
    mountPath: "/var/atlassian/application-data/bamboo"

  # A volume for 'shared-home' is required by Bamboo to effectively operate in multi-node
  # environment
  # https://confluence.atlassian.com/bamboo/bamboo-data-center-requirements-1063170547.html#BambooDataCenterrequirements-Sharedfilesystem
  #
  sharedHome:
    # Dynamic provisioning of local-home using the K8s Storage Classes
    #
    # 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: vsan-default-storage-policy

      # -- 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 Bamboo 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
    # Bamboo container.
    #
    subPath:

    # Modify permissions on shared-home
    #
    nfsPermissionFixer:
      # -- If 'true', this will alter the shared-home volume's root directory so that Bamboo
      # 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 Bamboo 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 Bamboo pods.
  # Note that this will not create any corresponding volume mounts;
  # those needs to be defined in bamboo.additionalVolumeMounts
  #
  additional: []

# Ingress configuration
#
# To make the Atlassian product available from outside of 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: true

  # -- 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: "contour"

  # -- 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: false

  # -- 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: atlassian-test.saltlabs.cloud

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

  # -- The custom annotations that should be applied to the Ingress Resource
  # when NOT using the K8s ingress-nginx controller.
  #
  annotations:
    cert-manager.io/issuer: ca-selfsigned-issuer

  # -- Set to 'true' if browser communication with the application should be TLS
  # (HTTPS) enforced. If not using an ingress and you want to reach the service
  # on localhost using port-forwarding then this value should be set to 'false'
  #
  https: false

  # -- 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:

# Bamboo configuration
#
bamboo:
  # -- To skip the setup wizard post deployment set this property to 'true' and
  # ensure values for all 'REQUIRED' and 'UNATTENDED-SETUP' stanzas
  # (see banner of this file) have been supplied.
  #
  # For release 1.0.0 this value is by default set to 'true' and should not be changed.
  #
  unattendedSetup: true

  # -- Override the server/agent broker URL; this is optional.
  #
  brokerUrl:

  # The security token with which the agent will authenticate to the Bamboo server.
  # The token should be set to a 40-character hexadecimal string. There are many ways
  # to generate a hex string like this, here is one: "xxd -l 20 -p /dev/urandom"
  # Additional details are here: https://confluence.atlassian.com/bamboo/agent-authentication-289277196.html
  #
  securityToken:
    # -- The name of the K8s Secret that contains the security token. When specified the token
    # will override the generated one. This secret should also be shared with the agent deployment.
    # An Example of creating a K8s secret for the secret below:
    # 'kubectl create secret generic <secret-name> --from-literal=security-token=<security token>'
    # https://kubernetes.io/docs/concepts/configuration/secret/#opaque-secrets
    #
    secretName:

    # -- The key (default `secretKey`) in the Secret used to store the Bamboo shared key.
    #
    secretKey: security-token

  # -- Whether to disable agent authentication. Setting this to true
  # skips the agent approval step in the UI. For more information see:
  # https://confluence.atlassian.com/bamboo/agent-authentication-289277196.html
  #
  # The default is false.
  #
  disableAgentAuth: false

  # UNATTENDED-SETUP
  #
  # -- The Bamboo DC license that should be used.
  # If supplied here the license configuration will be
  # skipped in the setup wizard.
  #
  license:
    # -- The secret that contains the license information
    #
    secretName:

    # -- The key (default 'licenseKey') in the Secret used to store the license information
    #
    secretKey: license

  # UNATTENDED-SETUP
  #
  # -- The admin user configuration, and credentials
  # that Bamboo should use. If supplied here the admin
  # configuration will be skipped in the setup wizard.
  #
  sysadminCredentials:
    # -- The secret that contains the admin user information
    #
    secretName:

    # -- The key in the Kubernetes Secret that contains the sysadmin username
    #
    usernameSecretKey: username

    # -- The key in the Kubernetes Secret that contains the sysadmin password
    #
    passwordSecretKey: password

    # -- The key in the Kubernetes Secret that contains the sysadmin display name
    #
    displayNameSecretKey: displayName

    # -- The key in the Kubernetes Secret that contains the sysadmin email address
    #
    emailAddressSecretKey: emailAddress

  # -- Bamboo can optionally import an existing exported dataset on
  # first-run. These optional values can configure the import file or
  # skip this stage entirely. For more details on importing and
  # exporting see the documentation:
  #
  # https://confluence.atlassian.com/bamboo/exporting-data-for-backup-289277255.html
  # https://confluence.atlassian.com/bamboo/importing-data-from-backup-289277260.html
  #
  import:
    # -- Import type. Valid values are `clean` (for a new install) or
    # `import`, in which case you should provide the file path. The
    # default is `clean`.
    #
    type: clean

    # -- Path to the existing export to import to the new
    # installation. This should be accessible by the cluster node;
    # e.g. via the shared-home or `additionalVolumeMounts` below.
    #
    path:

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

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

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

    # -- The Tomcat context path that Bamboo 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 Bamboo docker image
    # GID will default to 2005 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 Bamboo container.
    # However, this doesn't appear to work for NFS volumes due to a K8s bug: https://github.com/kubernetes/examples/issues/260
    #
    fsGroup: 2005

  # -- 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 Bamboo container. Set to 'false' to disable this behaviour.
  #
  setPermissions: true

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

    # -- JMS port
    #
    jms: 54663

  # Confirm that Bamboo is up and running 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 Bamboo container readiness probe,
    # after which the probe will start running.
    #
    initialDelaySeconds: 30

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

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

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

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

  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-bamboo-server/src/master/shutdown-wait.sh)
    # for details.
    #
    command: "/shutdown-wait.sh"

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

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

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

        # -- Initial Memory request by Bamboo 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, bamboo.cfg.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 Bamboo JVM, e.g.
  # system properties.
  #
  additionalJvmArgs: []

  # -- Specifies a list of additional Java libraries that should be added to the
  # Bamboo 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 Bamboo plugins that should be added to the
  # Bamboo 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 Bamboo 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 Bamboo
  # container. See https://hub.docker.com/r/atlassian/bamboo-server for
  # supported variables.
  #
  additionalEnvironmentVariables: []

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

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

  # -- Defines topology spread constraints for Bamboo 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
#
# Bamboo 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 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/bamboo/logs/access_log.*
  #   pos_file /tmp/bamboolog.pos
  #   tag bamboo-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: bamboo

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

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

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

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

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

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

# -- Standard K8s schedulerName that will be applied to all Bamboo 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 Bamboo pods
#
additionalContainers: []
#  - name: <name>
#    image: <image>:<tag>

# -- Additional initContainer definitions that will be added to all Bamboo 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