Manage heketi.db with a pv/pvc about gluster-kubernetes HOT 6 CLOSED

@ant31 IMO This will still not solve anything. We are more interested on removing the deploy-heketi part(ideas are welcomed) :).

from gluster-kubernetes.

@ant31 @MohamedAshiqrh See #37 for a possible solution to not needing deploy-heketi or even a volume for the DB.

from gluster-kubernetes.

@MohamedAshiqrh It's not solve the deploy-heketi , but it give a direction of the final setup.
My target is to do everything in a single command like:
kubectl create -f heketi --namespace glusterfs
and also be able to remove/rollback it
kubectl delete ns glusterfs

this is issue is part of this goal. Of course the bootstrap steps with deploy-heketi is the biggest issue.
I'm trying first to remove other manual steps before.

Is there a thread to discuss removing deploy-heketi?

from gluster-kubernetes.

@ant31 This goal is unattainable. The administrator must have knowledge of and provide a description for the block devices heketi will manage. There is no way to automatically or even safely detect storage and know what can and cannot be used. It should also be noted that a simple kubectl delete operation of any kind would not be able to properly remove all traces of heketi and GlusterFS on the nodes and their storage, and would require additional administrative tasks.

At present you can use the gk-deploy script to deploy heketi (and optionally GlusterFS) with a single command, provided you have a properly configured topology file. While the script does provide an --abort option in case the deployment fails partway, the clean and complete removal of a storage solution is a tricky and very site-specific endeavour, and is thus currently not in scope for this project.

To address the initial comment, in the current context it would not make much sense to manage the heketi DB storage volume as a PVC since heketi, as part of the current deployment process, assumes management and control over its own volume. If the intent is to simply the deployment and usage of heketi, I again point you to #37 as a likely step in that direction.

from gluster-kubernetes.

The administrator must have knowledge of and provide a description for the block devices heketi will manage

Thi is not about 'auto device' discovery, as proposed in #46, topology can be configured via configmap.

As for #37, I don't think deploying an etcd cluster is any easier than simply mounting a volume.

Thanks for your answers

from gluster-kubernetes.

@ant31 I'd just like to point out, you can do a simple kubectl create -f etcd.yml to deploy an etcd cluster in Kubernetes. If you're not using the gk-deploy script, this would greatly simplify the manual deployment of heketi on Kubernetes, which seems in line with the spirit of your original comment.

from gluster-kubernetes.