-
-
Notifications
You must be signed in to change notification settings - Fork 276
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Support emptyDir option #114
Comments
Yup, sounds reasonable. Can you do a spec proposal? |
So here my initial attempt at this: // VolumeSpec is the desired spec for storing mysql data
type VolumeSpec struct {
// EmptyDir to use if no PersistentVolumeClaim or HostPath is specified
// +optional
EmptyDir *corev1.EmptyDirVolumeSource `json:"emptyDir,omitempty"`
// HostPath to use instead of a PersistentVolumeClaim.
// +optional
HostPath *corev1.HostPathVolumeSource `json:"hostPath,omitempty"`
// PersistentVolumeClaim to use. It has the highest level of precedence,
// followed by HostPath and EmptyDir
// +optional
PersistentVolumeClaim *corev1.PersistentVolumeClaimSpec `json:"persistentVolumeClaim,omitempty"`
} We should also note that the volume spec should be initially immutable, since volume definitions for StatefulSets are immutable as well. |
Would also love this feature, any news on this? |
We will keep the current |
Signed-off-by: Dan Kozlowski <koz@planetscale.com>
I am working on an on-prem deployment with mysql-operator. For baremetal deployments, storage can come from
I am hoping that the final deployment is as simple as possible, without overly relying on quality of external storage provider. With 1 and 2, I faced issues.
Given these issues, can we support emptyDir as option for volumes? If the user knows what they are doing and make sure sufficient replicas are always available, all the shortcomings above can be overcome.
Happy to work on it, if this makes sense.
The text was updated successfully, but these errors were encountered: