Create a tool for kine <-> etcd migration

[stevefan1999-personal]

So here I've expressed my view on the embedded etcd support and my interest in it that it could be a potential termination to the domination of kubeadm, and how kine will be ultimately replaced to just using etcd.

However, one thing I noticed though is that because kine doesn't implement a full set of etcd features, it means we cannot effectively and correctly transfer the key-values in our kine backed datastore, so we may have to write a new tool to analyze the kine journal and then reconstruct it piece by piece in etcd.

I'm in the process of figuring out how to write such tool...meanwhile any input here would be positive.

[stevefan1999-personal]

Some simple brainstorming:

1. We can just pull out all the KV data and then asynchronously do batch put tx in target etcd. This however cannot preserve compaction and previous versioning history
2. We can use an ORM to speed up some SQL hassle, I've written a sample schema here
3. We can also create a simple BoltDB bucket and append kine data directly, then we instruct etcd to use the new db instead
4. Make sure the migration process is verifiable. But I'm not a good dev who can write tests...

[ElisaMeng]

velero is the tool for u?

[stevefan1999-personal]

@ElisaMeng not exactly, velero backs up K8S metadata, the one you seen in yaml manifests. I want a more efficient and painless way to "transmigrate"

[stale]

This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 180 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions.

[unixfox]

Bump

[stale]

This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 180 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions.

[ozeliurs]

bump ?