Can't roll out Wordpress chart with PV on AzureFile

[spinside]

Is this a request for help?:
Help

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
FEATURE REQUEST

I'd like to be able to set a value for:
volumeMounts:
- mountPath: "/mnt/azure"
name: volume

There is no parameter for this. If you want to use Azure File it is necessary to specify the mountPath

This is my current values.yaml:

## Bitnami WordPress image version
## ref: https://hub.docker.com/r/bitnami/wordpress/tags/
##
image:
  registry: docker.io
  repository: bitnami/wordpress
  tag: 4.9.5
  ## Specify a imagePullPolicy
  ## Defaults to 'Always' if image tag is 'latest', else set to 'IfNotPresent'
  ## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
  ##
  pullPolicy: IfNotPresent
  ## Optionally specify an array of imagePullSecrets.
  ## Secrets must be manually created in the namespace.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
  ##
  # pullSecrets:
  #   - myRegistrKeySecretName

## User of the application
## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
##
wordpressUsername: admin

## Application password
## Defaults to a random 10-character alphanumeric string if not set
## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
##
# wordpressPassword:

## Admin email
## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
##
wordpressEmail: user@example.com

## First name
## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
##
wordpressFirstName: FirstName

## Last name
## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
##
wordpressLastName: LastName

## Blog name
## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
##
wordpressBlogName: Kubernetes deployed Wordpress

## Table prefix
## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
##
wordpressTablePrefix: wp_

## Set to `yes` to allow the container to be started with blank passwords
## ref: https://github.com/bitnami/bitnami-docker-wordpress#environment-variables
allowEmptyPassword: "yes"

## SMTP mail delivery configuration
## ref: https://github.com/bitnami/bitnami-docker-wordpress/#smtp-configuration
##
# smtpHost:
# smtpPort:
# smtpUser:
# smtpPassword:
# smtpUsername:
# smtpProtocol:

externalDatabase:
## All of these values are only used when mariadb.enabled is set to false
  ## Database host
  host: localhost

  ## non-root Username for Wordpress Database
  user: bn_wordpress

  ## Database password
  password: ""

  ## Database name
  database: bitnami_wordpress

  ## Database port number
  port: 3306

##
## MariaDB chart configuration
##
mariadb:
  ## Whether to use the database specified as a requirement or not.
  ## If you want to use an external database, set this to false and supply details to externalDatabase above
  enabled: true

  ## MariaDB admin password
  ## ref: https://github.com/bitnami/bitnami-docker-mariadb/blob/master/README.md#setting-the-root-password-on-first-run
  ##
  # mariadbRootPassword:

  ## Create a database
  ## ref: https://github.com/bitnami/bitnami-docker-mariadb/blob/master/README.md#creating-a-database-on-first-run
  ##
  mariadbDatabase: bitnami_wordpress

  ## Create a database user
  ## ref: https://github.com/bitnami/bitnami-docker-mariadb/blob/master/README.md#creating-a-database-user-on-first-run
  ##
  mariadbUser: bn_wordpress

  ## Password for mariadbUser
  ## ref: https://github.com/bitnami/bitnami-docker-mariadb/blob/master/README.md#creating-a-database-user-on-first-run
  ##
  # mariadbPassword:

  ## Enable persistence using Persistent Volume Claims
  ## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/
  ##
  persistence:
    enabled: true
    ## mariadb data Persistent Volume Storage Class
    ## If defined, storageClassName: <storageClass>
    ## If set to "-", storageClassName: "", which disables dynamic provisioning
    ## If undefined (the default) or set to null, no storageClassName spec is
    ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
    ##   GKE, AWS & OpenStack)
    ##
    storageClass: "azurefile2"
    accessMode: ReadWriteMany
    size: 8Gi

## Kubernetes configuration
## For minikube, set this to NodePort, elsewhere use LoadBalancer or ClusterIP
##
serviceType: LoadBalancer
##
## serviceType: NodePort
## nodePorts:
##   http: <to set explicitly, choose port between 30000-32767>
##   https: <to set explicitly, choose port between 30000-32767>
nodePorts:
  http: ""
  https: ""
## Enable client source IP preservation
## ref http://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip
##
serviceExternalTrafficPolicy: Local

## Allow health checks to be pointed at the https port
healthcheckHttps: false

## Configure extra options for liveness and readiness probes
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes)
livenessProbe:
  initialDelaySeconds: 120
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 6
  successThreshold: 1
readinessProbe:
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 6
  successThreshold: 1

## Configure the ingress resource that allows you to access the
## Wordpress installation. Set up the URL
## ref: http://kubernetes.io/docs/user-guide/ingress/
##
ingress:
  ## Set to true to enable ingress record generation
  enabled: true

  ## The list of hostnames to be covered with this ingress record.
  ## Most likely this will be just one host, but in the event more hosts are needed, this is an array
  hosts:
  - name: example.com

    ## Set this to true in order to enable TLS on the ingress record
    ## A side effect of this will be that the backend wordpress service will be connected at port 443
    tls: false

    ## If TLS is set to true, you must declare what secret will store the key/certificate for TLS
    tlsSecret: wordpress.local-tls

    ## Ingress annotations done as key:value pairs
    ## If you're using kube-lego, you will want to add:
    ## kubernetes.io/tls-acme: true
    ##
    ## For a full list of possible ingress annotations, please see
    ## ref: https://github.com/kubernetes/ingress-nginx/blob/master/docs/annotations.md
    ##
    ## If tls is set to true, annotation ingress.kubernetes.io/secure-backends: "true" will automatically be set
    annotations:
    #  kubernetes.io/ingress.class: nginx
    #  kubernetes.io/tls-acme: true

  secrets:
  ## If you're providing your own certificates, please use this to add the certificates as secrets
  ## key and certificate should start with -----BEGIN CERTIFICATE----- or
  ## -----BEGIN RSA PRIVATE KEY-----
  ##
  ## name should line up with a tlsSecret set further up
  ## If you're using kube-lego, this is unneeded, as it will create the secret for you if it is not set
  ##
  ## It is also possible to create and manage the certificates outside of this helm chart
  ## Please see README.md for more information
  # - name: wordpress.local-tls
  #   key:
  #   certificate:

## Enable persistence using Persistent Volume Claims
## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/
##
persistence:
  enabled: true
  ## wordpress data Persistent Volume Storage Class
  ## If defined, storageClassName: <storageClass>
  ## If set to "-", storageClassName: "", which disables dynamic provisioning
  ## If undefined (the default) or set to null, no storageClassName spec is
  ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
  ##   GKE, AWS & OpenStack)
  ##
  storageClass: "azurefile2"
  ##
  ## If you want to reuse an existing claim, you can pass the name of the PVC using
  ## the existingClaim variable
  # existingClaim: your-claim
  accessMode: ReadWriteMany
  size: 10Gi

## Configure resource requests and limits
## ref: http://kubernetes.io/docs/user-guide/compute-resources/
##
resources:
  requests:
    memory: 128Mi
    cpu: 20m

## Node labels for pod assignment
## Ref: https://kubernetes.io/docs/user-guide/node-selection/
##
nodeSelector: {}

Version of Helm and Kubernetes:
Helm: v2.9.1
Kubernetes 1.9.6 AZURE/AKS

Which chart:
Wordpress

What happened:
MariaDB gets into a Init:CrashLoopBackOff state

What you expected to happen:
Wordpress starting and running with a persistent volume.

How to reproduce it (as minimally and precisely as possible):
Roll out AKS with AzureFile as storage
Then:

helm install --name b -f values.yaml stable/wordpress

Anything else we need to know:
Used this tutorial to set up Azure File:
https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv
I changed the Azure Disk example to Azure File

[krancour]

If you want to use Azure File it is necessary to specify the mountPath

This doesn't sound correct. (I work for Azure and have extensive experience with this chart.)

Can you should be how the sotrage class azurefile2 is defined?

[spinside]

I'm sorry still trying to learn. Got an example of a working yaml that defined these parameters and that was working.

This is my storageclass file:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azurefile2
provisioner: kubernetes.io/azure-file
parameters:
  storageAccount: $(StorageaccountName)

[krancour]

$(StorageaccountName) looks like some kind of placeholder. Are you using something to perform some substitution on this before deploying that storage class?

Also is whatever actual storage account you are attempting to use in the same resource group as your cluster? That matters. It must be in the same group.

[spinside]

The $(StorageaccountName) could identify my organisations name so I set this placeholder instead.

It actually is in the right resource group. I've double checked it to be sure.

When I add the following parameters the persistent volume problem is fixed.
persistence.accessMode=ReadWriteMany,persistence.storageClass=azurefile2

However the Wordpress Pod is going into a crashloopbackoff state.
I inspected the log file but it seems it just isn't ready yet when the healthcheck is done:

nami    INFO  Initializing apache
apache  INFO  ==> Reconfiguring PID file location...
nami    INFO  apache successfully initialized
nami    INFO  Initializing php
nami    INFO  php successfully initialized
nami    INFO  Initializing mysql-client
nami    INFO  mysql-client successfully initialized
nami    INFO  Initializing wordpress
wordpre INFO  WordPress has been already initialized, restoring...
mysql-c INFO  Trying to connect to MySQL server
mysql-c INFO  Found MySQL serv
er listening at jaundiced-otter-mariadb:3306
mysql-c INFO  MySQL server listening and working at jaundiced-otter-mariadb:3306
wordpre INFO  Upgrading WordPress Database ...

It looks like it is still upgrading the database when the container is killed and deployed again.

[spinside]

Okay, I got it to work. By delaying the health check it is working. But this does not seem to be the best way to do it. Is Azure File that slow?

[krancour]

Ah. Yes. I forgot about the issue of the healthcheck failing before initialization completes. Yes. It is that slow. You have to remember that underneath, that is a file share using Samba.

If you don't plan to scale to multiple pods, you can use Azure based storage that does not support ReadWriteMany. If you need to scale the pods, you need ReadWriteMany, and all options I know of that support that are slow.

[spinside]

I was trying to go for a HA but we will have to wait until the Azure file storage has improved their speeds for small files. Found the following issue:
Azure/AKS#223