Implement JSON Patch in Xds Translator#1606
Conversation
Relates to envoyproxy#24 Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
|
trying to fight one last issue wrt unmarshalling looks like the |
|
why there's a |
|
managed to solve the issue by setting the value of |
Codecov Report
@@ Coverage Diff @@
## main #1606 +/- ##
==========================================
- Coverage 61.38% 60.44% -0.94%
==========================================
Files 81 82 +1
Lines 12157 12404 +247
==========================================
+ Hits 7462 7498 +36
- Misses 4237 4416 +179
- Partials 458 490 +32
|
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
| // +k8s:deepcopy-gen=true | ||
| type JSONPatchOperation struct { | ||
| // Op is the type of operation to perform | ||
| Op string `json:"op"` |
There was a problem hiding this comment.
or rename to Type, and change to Enum?
There was a problem hiding this comment.
this naming is tied to JSONPatch spec, since we marshal this and directly pass it to https://github.com/evanphx/json-patch#create-and-apply-a-json-patch
There was a problem hiding this comment.
its part of the spec :)
https://datatracker.ietf.org/doc/html/rfc6902/#section-4
There was a problem hiding this comment.
I know it looks a bit ackward to have an "op" member inside the "Operation" object, but as Arko pointed out, it aligns with the RFC standard.
Below description is extracted from the RFC:
Operation objects MUST have exactly one "op" member, whose value indicates the operation to perform. Its value MUST be one of "add", "remove", "replace", "move", "copy", or "test"; other values are errors.
The following examples are from the same RFC. The Operation structure is the same as the JSONPatchOperation in this PR.
{ "op": "add", "path": "/a/b/c", "value": "foo" }
{ "path": "/a/b/c", "op": "add", "value": "foo" }
{ "value": "foo", "path": "/a/b/c", "op": "add" }
I think we can settle with the current implementation so we won't block user's custom extensions replying on the EnvoyPatchPolicy. It's internal to EG anyway, we can always go back and change it once we figure out a better way to handle it.
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arko@tetrate.io>
|
/retest |
Relates to #24