Add mapping layer for keys
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- go
Research direction
Start by reading the Store interface and the store configuration objects in libkv, then inspect the Consul implementation and its currently supported key paths. Compare the proposed namespace constants, mapping function, and NS methods against existing APIs; done means the design is agreed, existing callers remain compatible, and the additional namespaces and mappings are covered.
Written by the indexing model from the issue text.
Description
I think it would be useful to have a simple mapping function for each store to allow access to arbitrary keys. This is especially useful for stores like consul where currently only a subset of keys is accessible (e.g. /kv). There are additional keys available below /catalog/services for example.
I propose some changes to the API of libkv:
- Add namespace constants to libkv. These are for example
const (KV = 0, AGENT = 1, CATALOG = 2, SESSIONS=3, HEALTHCHECKS=4, ACLS=5, EVENTS=6, STATUS=7 )These are Consul namespaces which, except for KV, are not accessible by libkv. There could be more. - Add an optional
func map(namespace int, key string) (int, string)to each store's configuration object. This function allow mapping of namespaces and strings to different values as required by the store implementation. - Add a new ...NS() function to
Storefor each function accepting akey stringordirectory string. This function should have an additional first parameternamespace intwhich accepts the constants defined above. It applies the map-function to its parameters namespace and key and then calls the approriate store methods according to the mapped namespace and key.
If sane defaults are provided this should not require any change for any existing code outside of libkv.
It should provide allow to support more stores and their features.
Beside support for more namespaces in Consul the mapping function should allow schema changes and migrations from one store to another.
- Dominant language
- Go
- Stars
- 847
- Forks
- 204
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from docker/libkv
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
-
Difficulty 3/5 1-2 days Newbie friendliness 25/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 28/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100