Possible to provide a PVC or make deleting the deployment not delete the PVC?

[timothybean]

I am wondering, but have not been able to find and example of, telling the ArangoDeployment to not delete the PVC once created. I don't like the idea that if the deployment gets deleted that the data is deleted as well. Is there either a way to make it not do this on deletion of the deployment (make it where it manually has to be deleted) or to mount from a already generated PVC that is a separately managed configuration?

Thanks

[ajanikow]

Hello!

PVC is deleted with ArangoDeployment and you cannot provide your own PVC in the deployment definition, but you can provide a PVC template. It is done in the same way as for StatefulSet's.

PVC is a type that is used to be able to bind PersistentVolume to the Pods. Your volume (depends of StorageClass and provider used) is deleted with deletion of PersistentVolume.

Deletion of the PV depends on your StorageClass configuration, mostly on https://kubernetes.io/docs/concepts/storage/storage-classes/#reclaim-policy
If you want to keep your PV after ArangoDeployment deletion you should change this to Retain.

Once you cannot provide your custom PVC into ArangoDeployment, you can change the way how kubernetes will bind PV to newly created PVC. It is usually done by changing storageClassName to manual and manually binding PV to PVC's created by the operator.

If you want to reuse same PV in other ArangoDeployment, you need to remember you have to use the same encryption key.

Best Regards,
Adam Janikowski.

[timothybean]

Well,

That was clear as mud. Are there any examples of this, or is everyone that creates a cluster not relying on the underlying storage to actually be persistent? If the deployment gets removed, all the data is lost. How do you upgrade this thing? Right now, I can supply the sotrageclass and get the PV to bind the first time, but after a restart of the deployment then it wont bind to those PV again because the binding is for a different named pod. It doesn't look like it is setting up the pods as a statefulset where the names are consistent.

Trying to read what you are saying here, I would need to manually bind the PV to the PVC each time a deployment restarted, got upgraded, crashed, etc, or did anything that it would need to recover from to actually make it redundant?

Thanks

[ajanikow]

Hello!

First thing - we are using ArangoDeployment, not Deployment. So all limitations known for apps/v1 Deployment does not affect ArangoDeployment. In our case names are constant for ArangoDeployment managed pods and in sync with generated ArangoDB cluster resource names. All operation for upgrade or pod recreation works because name will not change when pod will be recreated.

In case when you remove ArangoDeployment CR and create new one - we do not want allow to bind PVC from different ArangoDeployment to newly created pods. Bootstrap of ArangoDB is complex procedure - so we cannot simply bind data from old ArangoDeployment because of different encryption keys. We know StatefulSet allow you to bind same PVC after StatefulSet recreation, but it would not work in our case.

So, unless you delete ArangoDeployment CR, data is persisted. It include upgrade, crash restore, machine restart. Upgrade of ArangoDeployment is just update of image in Spec section.

Solution with StorageClass is example of case when you want to keep data when you remove ArangoDeployment CR by mistake.

Best Regards,
Adam Janikowski.

[ajanikow]

Hello!

I will close this issue, please reopen this if you have further questions.

Best Regards,
Adam Janikowski.

[phal0r]

Hi @ajanikow ,
sorry for highjacking this old ticket, but it is exactly what is unclear to me, too. I think, that it is not uncommon to delete a CRD for a statefulset and keep the PVCs and redeploy. This is the way other operators work. Naming of the PVCs is aligned to the name of the CRD, so 2 different CRDs won't try to take the same PVCs. But redeploying a CRD with the same name will pick them up. This allows for more flexibility.

An ArangoDB instance should be able to catch up with an existing PVC and data. In fact, it's the same situation as restarting a plain old windows/linux service. Obviously it does not delete the data either.

Managing this via reclaimPolicy is very implicit knowledge and probably does not allow for easy reuse of a volume by a new CRD.

So currently it's quite easy to delete all data via kubectl when the CRD gets deleted and from my personal experience this is not the way other operators of statefulset have implemented such logic. Mostly PVCs remain after deletion of the CRD, so a new CRD with the same name will just pick up existing data.

I would appreciate a solution, where PVCs would remain and can be reused. (could be also a new paramater in the CRD spec to not break current logic)

[tradetree]

I agree that it is important to understand the architecture of the PVC, at the very least. Just closing the ticket does not help us to understand what the architecture is that causes this effect, and therefore how it may be remedied.