Implement ".spec.storage" about etcd-operator HOT 6 CLOSED

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

from etcd-operator.

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.

from etcd-operator.

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.

from etcd-operator.

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

from etcd-operator.

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?

from etcd-operator.

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)

from etcd-operator.