Skip to content
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

Closed
smanpathak opened this issue Sep 10, 2018 · 4 comments · Fixed by #205
Closed

Feature Request: Support emptyDir option #114

smanpathak opened this issue Sep 10, 2018 · 4 comments · Fixed by #205
Milestone

Comments

@smanpathak
Copy link
Contributor

I am working on an on-prem deployment with mysql-operator. For baremetal deployments, storage can come from

  1. A storage provider from commercial storage vendor.
  2. Host local volumes/NFS
  3. Host directory.

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.

  1. For external storage providers (at least the ones I worked on), the K8s integration is not that great. These providers don't scale well and make the deployment unstable.
  2. The local volume provider: (https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume/provisioner) suffers from issues: (a) It does not clean up properly, so if a new statefulset re-uses a deleted volume, it sometimes gets unclean state from previous DB (b) If a node dies, the replica is lost because volume claim is specific to the lost node.

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.

@calind
Copy link
Member

calind commented Sep 12, 2018

Yup, sounds reasonable. Can you do a spec proposal?

@calind
Copy link
Member

calind commented Nov 2, 2018

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.

@calind calind added this to the 0.2.x milestone Nov 20, 2018
@Fgruntjes
Copy link

Would also love this feature, any news on this?

@calind calind modified the milestones: 0.2.x, 0.2.3 Jan 7, 2019
@calind
Copy link
Member

calind commented Jan 14, 2019

We will keep the current VolumeSpec inlined but deprecated, and move forward with the proposed change. We will drop the inlined PVC spec once we bump the resource version. The migration should be done without any user intervention.

chapsuk pushed a commit to chapsuk/mysql-operator that referenced this issue Oct 16, 2023
Signed-off-by: Dan Kozlowski <koz@planetscale.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants