Does this project plan to build non-etcd storage implementations?

[clarkmcc]

With the power of CustomResourceDefinitions, Kubernetes provides a flexible platform for declarative APIs of all types, and the reconciliation pattern common to Kubernetes controllers is a powerful tool in building robust, expressive systems. (README)

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?

[CodeNoobKing]

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.

[andrewrynhard]

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

[imjasonh]

I'd like to keep this project focused on improving the API server layer above the storage layer, for a couple reasons:

1. Trying to change how the API layer interacts with the storage layer, while making the storage layer flexible to other implementations, seems like it adds a lot more moving parts, which makes both harder.
2. Other projects are already focused on being able to make the storage layer more configurable (e.g., kine), and they're already seeing benefits from that.

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.

[smarterclayton]

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.

[smarterclayton]

Captured this note in #74 as:

In the short term, it would not be a goal of this investigation to replace the underlying storage implementation etcd, but it should be possible to more easily inject the appropriate initialization code so that someone can easily start an API server that uses a different storage mechanism.

[afritzler]

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.

[pweil-]

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.

[akutz]

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 kine and clicked on docs/investigations/minimal-api-server.md and not the issues section ☹️ .