-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Allow using kubernetes PVCs for stateful resources #10804
Milestone
Comments
@xetys if you know how to implement this feature in a cloud-agnostic way and keep things working out of the box in most cases. I'm all for this. Do you have time right now to develop this feature? |
xetys
added a commit
to xetys/generator-jhipster
that referenced
this issue
Nov 20, 2019
with this feature, all stateful services (such as `Deployment`, `StatefulSet` for databases) will use persistent volume claims instead of `emptyDir`. There are two new options for the user, so it is possible to enable dynamic storage provisioning and specify a custom storage class. Another update in context with this PR, is that `StatefulSet`s are no longer generated with `volumeClaimTemplate` by default, as it was before. Instead, the data dirs are either `emptyDir`, if dynamic storage provisioning is disabled, or we use volume claim templates with the same configuration as for the deployments. close jhipster#10804
4 tasks
@PierreBesson sure, already started ;) |
xetys
added a commit
to xetys/generator-jhipster
that referenced
this issue
Nov 25, 2019
with this feature, all stateful services (such as `Deployment`, `StatefulSet` for databases) will use persistent volume claims instead of `emptyDir`. There are two new options for the user, so it is possible to enable dynamic storage provisioning and specify a custom storage class. Another update in context with this PR, is that `StatefulSet`s are no longer generated with `volumeClaimTemplate` by default, as it was before. Instead, the data dirs are either `emptyDir`, if dynamic storage provisioning is disabled, or we use volume claim templates with the same configuration as for the deployments. close jhipster#10804
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Overview of the feature request
As already discussed in #5173 or #9622, our kubernetes sub-generator generates all "stateful resources" (such as MySQL, PostgreSQL, etc.) with
emptyDir
as volume definition.I propose the following add-on:
When
jhipster kubernetes
asks its prompts, it should askIf the user chooses the last option, an additional question asks the
storageClassName
.Motivation for or Use Case
I think the motivation is clear: we want to define non-empheral storage as we want to keep our data. In the past discussions, we were concerning about the cloud-specific storage configurations. AFAIK, kubernetes developed the concept of storage classes and persistent volume claim with the aim of decouple persistence with the persistent provider.
In usual clusters, with a recent kubernetes version, you just can create a PVC without specifying
storageClassName
or annotations. If the cluster has a default storage class, kubernetes assumes such an empty definition as a PVC for the default storage class implicitly.In scenarios, where cluster administrators enable several storage classes, we can ask the user for the storage class name. In earlier versions of k8s, there was no clear standard about how to set the storage class name, as you could either use the property, or
alpha
/beta
annotations. However, as of today, it is well established.I see the following tasks here:
Related issues or PR
The text was updated successfully, but these errors were encountered: