Propose clarification covering "persistence" across reboots and the term volatile #1
Conversation
robshakir
commented
Sep 9, 2024
robshakir
commented
* (M) docs/motivation.md
- Clarify that dynamic configuration is not expected to persist
across reloads.
- Clarify that dynamic configuration is expected to persist across
control plane switchovers.
* (M) docs/motivation.md
- Rename `dynamic` to `volatile` to ensure that do not overload
terms defined in the bootz specification.
- Minor clarifications.
| described in this document). Therefore, we propose that where payloads are | ||
| generated for the `Modify` RPC, we give these a new place within the OpenConfig | ||
| schema, particularly, defining a new | ||
| `volatile`/`ephemeral` subtree to correspond with the `config` and |
There was a problem hiding this comment.
Maybe the design decisions for modeling should be outside the scope of the motivation doc?
That said, would an annotation be more appropriate?
There was a problem hiding this comment.
They can be moved, yes.
I'm not sure how an annotation would work here -- what are you proposing? There are other PRs that cover how the content of these RPCs are proposed to be generated. PTAL at #6.
There was a problem hiding this comment.
The volatile container could have an annotation so there is a property in yang identifying the node as volatile.
It might be useful so yang aware code can identify volatile leafs programmatically versus relying on a "magic" container name. (Although I think using "volatile" as a container name also makes sense from a style perspective. I would do both the annotation an the container name)
An analogous entity is using the yang config statement, but also as an OC style guide, we use a container named 'config'.
There was a problem hiding this comment.
Ah, I see -- yes, annotating as well as a container name makes sense. I think we must have a container name for consistency. The alternate suggestion of having an annotation on an existing config leaf would be possible but add more complexity of magic in the tooling to know that such an annotation means that there is another path for the leaf.
There was a problem hiding this comment.
Ok, agreed that we should have both: a container and an annotation such as config-volatile, as this is the most explicit.
|
can this commit message/title be updated to reflect that this commit also clarifies the term |
dplore
changed the title
I updated the title |
