Implement ".spec.storage"

[kvaps]

Internally we agreed to extend spec like this:

 ---
 apiVersion: etcd.aenix.io/v1alpha1
 kind: EtcdCluster
 metadata:
   name: test
   namespace: ns1
 spec:
   image: "quay.io/coreos/etcd:v3.5.12"
   replicas: 3
+  storage:
+    persistence: true # default: true, immutable
+    storageClass: local-path
+    size: 10Gi
 status:
   conditions:
   - lastProbeTime: null
 	lastTransitionTime: "2024-03-06T18:39:45Z"
 	status: "True"
 	type: Ready

[kvaps]

There were also an idea of reuisng VolumeSource type.

But there were some concerns about security and stability, eg. user can use hostPath volumes and compromise the system.

Thus it's up to discussion.

[Kirill-Garbar]

I didn't get how it can be our problem if user defines hostPath. Usually k8s admins create policies (old PSP, kyverno, OPA gatekeeper) to prevent k8s users from creation unwanted (compromising) pod settings (privileged, hostNetwork, hostPath, etc
..)
If we want to help with it or we think that some types are not goot to use, we can add it to validation webhook - allow only some of the volume types. But again, I think it is not our decision to make for the user.

[kvaps]

How about creating custom type, with selecting only specific methods we want to support?

Otherwise there might be potencial problems with supporting resizing for various backends (eg. NFS and iscsi). One more thing is that most of these methods are deprecated in favor CSI plugins

[sircthulhu]

I think we should use spec.storage field from proposal #62

[gecube]

I just understood that we can use storage field for zero downtime migration of etcd from one storage to another. @kvaps What do you think?

[kvaps]

I think we should use spec.storage field from proposal #62

Agree

I just understood that we can use storage field for zero downtime migration of etcd from one storage to another.

Sounds like an idea for additional option.
The same about cleaninng up PVC after EtcdCluster get removed.

Just opened this question here
#67 (comment)