[stable/wordpress] version 0.7.8/0.7.9 don't work on minikube

[pablorsk]

BUG REPORT:

If I do helm install stable/wordpress with GCE works all fine (it's great!) but when I try with minikube, never start.

Problem on maria-db pod:

PersistentVolumeClaim is not bound: "unsung-hyena-mariadb"
Back-off restarting failed container
Error syncing pod

Problem on wordpress pod:

PersistentVolumeClaim is not bound: "unsung-hyena-wordpress"
Error: lstat /tmp/hostpath-provisioner/pvc-d33720c3-f345-11e7-835d-080027cf3459: no such file or directory
Error syncing pod

PVC are OK

Version of Helm and Kubernetes:

$ helm version
Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.0", GitCommit:"925c127ec6b946659ad0fd596fa959be43f0cc05", GitTreeState:"clean", BuildDate:"2017-12-15T21:07:38Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"0b9efaeb34a2fc51ff8e4d34ad9bc6375459c4a4", GitTreeState:"clean", BuildDate:"2017-11-29T22:43:34Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"}
$ minikube version
minikube version: v0.24.1

Which chart:

• stable/wordpress 0.7.8 and 0.7.9

What happened:

With GCE works fine helm install, but with minikube fails.

What you expected to happen:

Start ok like GCE.

How to reproduce it

minikube start
helm init
helm install stable/wordpress

Anything else we need to know:

I try with minikube

• Kubernetes v1.8.0
• minikube v0.24.1 and v0.21.0
• stable/wordpress 0.7.8 and 0.7.9

[pablorsk]

UPDATE on GCE: new install on the same cluster

I create a new cluster and install perfect the first helm app: 👍

helm install --name myfirstblog stable/wordpress  --version 0.7.8

But, when I install a second blog: 👎

helm install --name mysecondblog stable/wordpress  --version 0.7.8

wordpress and db deployment says

❌ PersistentVolumeClaim is not bound: "mysecondblog-mariadb" (repeated 2 times) 😢

[mattfarina]

cc @prydonius @tompizmor @sameersbn

[prydonius]

@pablorsk looks like the issue is in the storage provisioners on both Minikube and GCE. Does kubectl describe pvc <releasename>-mariadb give anything away?

[krancour]

This is a known issue with minikube v0.24.1: kubernetes/minikube#2256

[pablorsk]

I test again today. On GCE, clean cluster, works fine :)

On minikube v0.24.1, don't work. Thanks @krancour.

Also if anyone need more information, here is my steps

$ kubectl get svc --all-namespaces
NAMESPACE     NAME                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE
default       kubernetes             ClusterIP   10.96.0.1        <none>        443/TCP         2d
kube-system   kube-dns               ClusterIP   10.96.0.10       <none>        53/UDP,53/TCP   2d
kube-system   kubernetes-dashboard   NodePort    10.100.236.125   <none>        80:30000/TCP    2d
kube-system   tiller-deploy          ClusterIP   10.99.168.100    <none>        44134/TCP       2d

$ helm init
$ helm install --name myfirstblog stable/wordpress

I wait 10 minutes....

$ kubectl describe svc myfirstblog-mariadb
Name:              myfirstblog-mariadb
Namespace:         default
Labels:            app=myfirstblog-mariadb
                   chart=mariadb-2.1.1
                   heritage=Tiller
                   release=myfirstblog
Annotations:       <none>
Selector:          app=myfirstblog-mariadb
Type:              ClusterIP
IP:                10.104.214.102
Port:              mysql  3306/TCP
TargetPort:        mysql/TCP
Endpoints:         
Session Affinity:  None
Events:            <none>

$ kubectl describe pvc myfirstblog-mariadb
Name:          myfirstblog-mariadb
Namespace:     default
StorageClass:  standard
Status:        Bound
Volume:        pvc-56e1abee-f58a-11e7-8dd2-080027cf3459
Labels:        app=myfirstblog-mariadb
               chart=mariadb-2.1.1
               heritage=Tiller
               release=myfirstblog
Annotations:   control-plane.alpha.kubernetes.io/leader={"holderIdentity":"a925d9a8-f589-11e7-8994-080027cf3459","leaseDurationSeconds":15,"acquireTime":"2018-01-09T22:13:37Z","renewTime":"2018-01-09T22:13:39Z","lea...
               pv.kubernetes.io/bind-completed=yes
               pv.kubernetes.io/bound-by-controller=yes
               volume.beta.kubernetes.io/storage-provisioner=k8s.io/minikube-hostpath
Finalizers:    []
Capacity:      8Gi
Access Modes:  RWO
Events:
  Type    Reason                 Age              From                                                           Message
  ----    ------                 ----             ----                                                           -------
  Normal  ExternalProvisioning   1m (x2 over 1m)  persistentvolume-controller                                    waiting for a volume to be created, either by external provisioner "k8s.io/minikube-hostpath" or manually created by system administrator
  Normal  Provisioning           1m               k8s.io/minikube-hostpath a925d9a8-f589-11e7-8994-080027cf3459  External provisioner is provisioning volume for claim "default/myfirstblog-mariadb"
  Normal  ProvisioningSucceeded  1m               k8s.io/minikube-hostpath a925d9a8-f589-11e7-8994-080027cf3459  Successfully provisioned volume pvc-56e1abee-f58a-11e7-8dd2-080027cf3459

I wait for a new release? with minikube v0.21.0 fails too.

[mattfarina]

@krancour Thanks for finding the bug.

It appears the next release of minikube should fix this. Hope that's soon.

I've experienced the same problem.

[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.

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