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: CRDs for provisioning Databases with code. #574

Open
devantler opened this issue Aug 5, 2024 · 4 comments
Open

Feature Request: CRDs for provisioning Databases with code. #574

devantler opened this issue Aug 5, 2024 · 4 comments

Comments

@devantler
Copy link

devantler commented Aug 5, 2024

I just saw your blog post on the CNCF blog, and wanted to check out Everest. It looks really promising, and I say that as a person who have deliberately choosen to use Managed Databases over self-hosted databases for quite some time, as I still feel there is a large amount of risk in self-hosting these (largely due to the complexity of doing so, and the resulting risk of failing to do it right).

I understand the need to simplify provisioning of databases by providing a UI, but I am a big GitOps fan, and thus I prefer to keep all my infrastructure as code. Have you considered CRDs as an alternative API for provisioning Databases with Everest? Applying something like this while knowing Everest handles all my concerns would be awesome:

apiVersion: database.everest.io/v1
kind: Database
metadata:
  name: postgres
spec:
  database:
    type: postgresql
    ...
  backups:
    frequency: 3h
    store: some-url-to-a-blob-store
    ...

Ideally the CRDs would provide all the same options as found in the UI.

I believe this would make Everest fit better into GitOps workflows as that assumes raw manifests to be the primary API for configuring all things running in the cluster. Having many UIs in such a setup actually makes everything much more complicated, as one of the benefits of not having to visit UIs to make configurations is that you can provision everything from scratch, which is quite nice for CI/CD, and in general.

If you are considering this approach, I might also suggest to make it complimentary to the UI, such that any Database applied from code, shows in the UI, and such that any database created in the UI has its own CR applied.

@mayankshah1607
Copy link
Member

Hi @devantler,

Thanks for trying out Everest and providing feedback!

Everest does in fact have its own CRDs and Kubernetes operator, which is used to provision and manage database clusters (together with the Percona Kubernetes operators). The Everest API server internally operates on these CRs, acting as a proxy to the Kubernetes API and providing additional validation.

While we currently recommend using the Everest API to manage your databases, you can still manage them directly using the CRDs, or using a GitOps tool of your choice.

@devantler
Copy link
Author

That is awesome @mayankshah1607!

Do you have any documentation on how to use the CRDs, I might have missed it. What you are describing here, Is exactly what I was looking for/expecting initially :-)

@recharte
Copy link
Collaborator

recharte commented Aug 6, 2024

Hi @devantler,

Since our initial focus was to provide an easy to use UI/API, we focused on documenting that part so unfortunately we don't yet have a comprehensive documentation for interfacing directly with the Everest operator.

Nonetheless, I can point you to our tests suite which will probably be very useful for you since it features several examples.

Here are some of them (using PostgreSQL as an example but you can find MySQL and MongoDB examples if you navigate to the corresponding directories) :

@devantler
Copy link
Author

Thanks for sharing! Feel free to close this issue, if you do not want to use it to track progress on the docs :-)

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

No branches or pull requests

3 participants