Charts: mariadb PV claim is not disabled in Wordpress chart

[devlaptop]

I am trying to deploy Wordpress on a single node kubernates cluster and don't have Persistent volumes configured on Kubernates, and the k8s cluster is running on Bluemix so I don't think it supports dynamic provisioning of volumes.

Hence I cannot get the application to run even with --set persistence.enabled=false, because although this works for Wordpress, PVC is still used for mariadb.

Is there a way to still run this without requiring persistent volumes ?

[kachkaev]

Same here. Tried quite a few things in --set before realising that the claim comes from a dependent chart, not the wordpress chart itself.

helm install --name wordpress-test --set "persistence.enabled=false" --dry-run stable/wordpress --debug

Output:

COMPUTED VALUES:
...
persistence:
  accessMode: ReadWriteOnce
  enabled: false
  size: 10Gi
...
---
# Source: wordpress/charts/mariadb/templates/pvc.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: wordpress-test-mariadb
  labels:
    app: wordpress-test-mariadb
    chart: "mariadb-0.6.2"
    release: "wordpress-test"
    heritage: "Tiller"
  annotations:
    volume.alpha.kubernetes.io/storage-class: default
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: "8Gi"
...

The whole section # Source: wordpress/charts/mariadb/templates/pvc.yaml was not expected here.

@bcorijn @scottrigby could you please help? (saw you editing the wordpress chart recently)

I'm a total newbie in k8s and helm, this is my first day =)

[bcorijn]

@kachkaev: I'm not in any way officially related to this chart or to WP, but I think you'll have to add --set "mariadb.persistence.enabled=false" to disable the persistency of mariadb as well.

[kachkaev]

Thanks for your superquick reply @bcorijn! This worked:

helm install --name wordpress-test-02 --set "persistence.enabled=false,mariadb.persistence.enabled=false" stable/wordpress

Pods still dont start due to 'insufficient cpu' on my 1core/1gb master, but that's a completely different story 😄

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close