-
Notifications
You must be signed in to change notification settings - Fork 381
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
Does this project plan to build non-etcd storage implementations? #54
Comments
I have the same question and I found that there is an opensource project k3s-io/kine which wrap sql database through etcd api. That project maybe what your are seeking for. |
I would like to see this now that #48 is on the table. In https://github.com/cosi-project we would like to have in-memory database (the data can easily be repopulated on every reboot). |
I'd like to keep this project focused on improving the API server layer above the storage layer, for a couple reasons:
I do think that there's a natural overlap between kcp improving API server flexibility and other projects improving storage layer flexibility, but at least for now I think they're separate projects. |
One challenge is upstream (and i was part of this) were pretty clear that different backends was a "further in the future, not now" thing. I agree with Jason in that if we can take a specific lane it helps us. I think further out it might be useful, it would just be "does it help support new capabilities". Having a reusable apiserver as per #48 that people are willing to pick up support for might accelerate the ability of the api-machinery SIG to make different backends more possible. But it's definitely a complex topic that might be best pursued as a subtopic of other projects or a point of collaboration with others. |
Captured this note in #74 as:
|
As somebody who is fiddling around with https://github.com/k3s-io/kine at the moment I would also love to see this moving forward. |
Since this has been captured in the PR mentioned above as a non-goal of this particular prototyping effort I'm going to go ahead and close the issue. Feel free to reopen if there is disagreement. |
I know this was closed, but I did want to capture that I recently started a thread on this topic in the #kcp-prototype channel on Kube Slack. I was not aware of this issue when I started the thread, which is sad since I actually did search this repository for |
While etcd is great for distributed systems, it's less ideal for embedded systems where single binary deployments are ideal. Do you aim to provide support for something like BoltDB or Badger?
The text was updated successfully, but these errors were encountered: