Rook: minikube : monitor data filesystem reached concerning levels of available storage space

[ksingh7]

Is this a bug report or feature request?

• Bug Report

Deviation from expected behavior:

# kubectl logs -n rook-ceph rook-ceph-mon-a-6d7b4dbf96-r26wf
debug 2019-03-28 00:34:27.885 7faf2d5f0a00  0 ceph version 13.2.5 (cbff874f9007f1869bfd3821b7e33b2a6ffd4988) mimic (stable), process ceph-mon, pid 1
debug 2019-03-28 00:34:27.886 7faf2d5f0a00 -1 error: monitor data filesystem reached concerning levels of available storage space (available: -2147483648% 0 B)
you may adjust 'mon data avail crit' to a lower value to make this go away (default: 5%)

```[root@beast ceph]# kubectl get po -n rook-ceph rook-ceph-mon-a-6d7b4dbf96-r26wf
NAME READY STATUS RESTARTS AGE
rook-ceph-mon-a-6d7b4dbf96-r26wf 0/1 CrashLoopBackOff 2 38s
[root@beast ceph]#

**Expected behavior:**
rook ceph should get install in a minikube environment

**How to reproduce it (minimal and precise):**
<!-- Please let us know any circumstances for reproduction of your bug. -->
- setup minikube
- git clone rook-ceph
- kubectl create -f operator.yaml
- update dataDirHostPath in ``cluster.yaml`` was set to ``/data/rook`` 
- kubectl create -f cluster.yaml

**Environment**:
* OS (e.g. from /etc/os-release): Host OS Fedora
* Kernel (e.g. `uname -a`): Host OS kernel 4.x
* Cloud provider or hardware configuration:
* Rook version (use `rook version` inside of a Rook Pod): master branch
* Kubernetes version (use `kubectl version`): 1.4
* Kubernetes cluster type (e.g. Tectonic, GKE, OpenShift): minikube
* Storage backend status (e.g. for Ceph use `ceph health` in the [Rook Ceph toolbox](https://rook.io/docs/Rook/master/toolbox.html)):

kubectl logs -n rook-ceph rook-ceph-mon-a-6d7b4dbf96-r26wf

debug 2019-03-28 00:34:27.885 7faf2d5f0a00 0 ceph version 13.2.5 (cbff874f9007f1869bfd3821b7e33b2a6ffd4988) mimic (stable), process ceph-mon, pid 1
debug 2019-03-28 00:34:27.886 7faf2d5f0a00 -1 error: monitor data filesystem reached concerning levels of available storage space (available: -2147483648% 0 B)
you may adjust 'mon data avail crit' to a lower value to make this go away (default: 5%)

[root@beast scripts]# minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ _| |/' _ \| || , < ( ) ( )| '_ /'__\ | ( ) ( ) || || ( ) || || |\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)\___/'(_,__/'____)

$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 25M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
tmpfs 3.9G 72K 3.9G 1% /tmp
/dev/sda1 17G 2.7G 14G 17% /mnt/sda1
/hosthome 28G 17G 11G 61% /hosthome
$

dataDirHostPath in ``cluster.yaml`` was set to ``/data/rook`` 

# In Minikube, the '/data' directory is configured to persist across reboots. Use "/data/rook" in Minikube environment.
dataDirHostPath: /data/rook

```[root@beast ceph]# kubectl get po -n rook-ceph rook-ceph-mon-a-6d7b4dbf96-r26wf
NAME                               READY   STATUS             RESTARTS   AGE
rook-ceph-mon-a-6d7b4dbf96-r26wf   0/1     CrashLoopBackOff   2          38s
[root@beast ceph]#

[ksingh7]

1192 similar but didn't worked after setting dataDirHostPath in cluster.yaml to /data/rook

[leseb]

That's what I do to overcome this on my dev env:

minikube ssh "sudo rm -rf /mnt/vda1/rook/ /var/lib/rook && sudo mkdir /mnt/vda1/rook/ && sudo ln -sf /mnt/vda1/rook/ /var/lib/"

With that you have enough space to deploy mons and osds.

I'm closing this, feel free to re-open if you have more concern.

[ksingh7]

Thanks @leseb , your on-liner works like charm

[infa-ddeore]

That's what I do to overcome this on my dev env:

minikube ssh "sudo rm -rf /mnt/vda1/rook/ /var/lib/rook && sudo mkdir /mnt/vda1/rook/ && sudo ln -sf /mnt/vda1/rook/ /var/lib/"

With that you have enough space to deploy mons and osds.

I'm closing this, feel free to re-open if you have more concern.

on my mac with minikube version: v1.3.0 i had to change vda1 to sda1