Feature Request: CRDs for provisioning Databases with code.

[devantler]

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]

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]

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]

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) :

• Create a DB cluster
• Create a DB cluster with a daily backup schedule
• Trigger an on-demand backup
• Restore from a backup

[devantler]

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