Adjust gNMI SetRequest Update handling for list keys + value payloads #176
Conversation
|
@gcsl - PTAL - this just tightens up the protocol around disallowing list keys to be included in the value payload since they are immutable in this context |
|
@dplore - looking for review here. This has been a long standing PR - it looks like some protocol needs to be put in place across various repos to ensure distribution of review - Thx |
dplore
left a comment
dplore
left a comment
There was a problem hiding this comment.
There is a behavioral change here regarding support for idempotent behavior that I don't think we want to make. See comments.
| or replace message specifying a path of `/a/f[k1=10][k2=20]` setting the value | ||
| of `k1` to 100 MUST be considered erroneous, and a status code of | ||
| `InvalidArgument (3)` specified. | ||
| of `k1` to either the same value (10) or an alternate value (100) MUST be |
There was a problem hiding this comment.
To support idempotent behavior, I believe setting a node which is also a list key to the same value it already has should be permitted. Only changing the node's value must be an error.
| path, and as their own elements within the value, then this MUST be considered | ||
| an error by the target system - and a status code of `InvalidArgument (3)` | ||
| specified. Targeting a list member with update or replace operations that | ||
| modify it's own keys in either conflicting or identical fashion is not |
There was a problem hiding this comment.
To support idempotent behavior, identical update/replace should be permitted. Agreed that conflicting node / list key values must return an error. I think that is already covered by the last bullet point in this stanza,
2 participants
Clarify that an Update to a list member targeted in the Path cannot include
those list keys in the value payload either as a direct descendant or ultimate
leafref'd node.
Since you cannot modify the list keys on a targeted Path, disallow the contents
altogether in the payload. At best, the same values could be specified but
since the Path is unprefixed while
JSON_IETFencoding currently remainsprefixed, an association needs to be drawn from a schema set perspective.
In addition, this reduces pointless and redundant bytes on the wire.