Should Customizer objects use (JSONPath, replacement-value) or patch style? #453
MikeSpreitzer
started this conversation in
General
Replies: 2 comments
-
FYI, following are some go-based implementations of JSONPath that I found.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
it appears, based on your notes, that ohler55 and spyzhov look like a good start. Are either of these communities that would be responsive to issues/PRs? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In the current customization API, a Customizer has a series of Replacements; each one is a pair of (JSONPath pointer to location in object, JSON replacement value). JSONPath has the advantage that it is a well established in general and in Kubernetes (you can use it in kubectl output, for example) and expressive way of selecting part of an object. This (pointer, replacement) style of customization is also widely used. However, JSONPath is not all that widely established. I went looking for an implementation in go that supports modification of a data structure that was produced by
encoding/json.Unmarshal(str, map[string]interface{})
and came up empty. The closest I found was one that supports modifications but (a) the input and output are strings rather than data structures and (b) the pointer syntax is only a close approximation of a subset of JSONPath. The current implemenation of customization uses that. Someone could write a better implementation for our purposes. Note that https://goessner.net/articles/JsonPath/index.html incorporates "Expressions of the underlying scripting language" and "Filter expressions". These could be invitations to quite a lot of work. But in the use case here I think we do not need support for all possible expressions. Since the author of the Customizer can look at the object before customization, literal indices will suffice; one could go a little further for convenience, making a tradeoff between implementation and convenience.A possible alternative approach would be to use patching a la kubectl patch. This is also well established in the Kubernetes milieu. Note that
kubectl patch
supports three different kinds of patch: JSON Patch, JSON merge patch, and kube's own unique "strategic merge patch". We would not necessarily have to support all three; we could pick just one. Which one? If I had to pick just one, it would be strategic merge patch because it is the one I use most often. Also for this approach, I do not know a good re-usable implementation. You can see what the apiserver does at https://github.com/kubernetes/apiserver/blob/be7d2eb4732cd3718f71ddd5a9eb3c74ab04d40e/pkg/endpoints/handlers/patch.go#L366-L413 for the first two and at https://github.com/kubernetes/apiserver/blob/be7d2eb4732cd3718f71ddd5a9eb3c74ab04d40e/pkg/endpoints/handlers/patch.go#L423-L447 for the last one. That server-side code is thoroughly intertwined with apiserver stuff.Beta Was this translation helpful? Give feedback.
All reactions