Reorganization of gNMI updates and deletes requests for Cisco XRd devices#303
Reorganization of gNMI updates and deletes requests for Cisco XRd devices#303giacoliva wants to merge 2 commits intosdcio:mainfrom
Conversation
| if err != nil || len(entry) == 0 { | ||
| // check if the OptionalInstance (!require-instances [https://datatracker.ietf.org/doc/html/rfc7950#section-9.9.3]) | ||
| if s.schema.GetField().GetType().GetOptionalInstance() { | ||
| if !s.schema.GetField().IsMandatory { |
There was a problem hiding this comment.
This is two different things. Mandatory is a container option, mandates, that the mandatory attributes of that container have to be present.
The OptionalInstance is a leafref based option. So the default behaviour is that the referenced attribute must exist. Say under some routing protocol you reference an interface. So that interface must be created. but if the optional flag is set, it is ok, that the interface is reference, without being config-wise created. We will create a warnign for that, just lettings the user know that the referenced instance does not exist.
| b, err := strconv.ParseBool(v) | ||
| if err != nil { | ||
| return nil, err | ||
| if strings.Contains(strings.ToLower(v), "true") { |
There was a problem hiding this comment.
What's the issue here? Why contains? we can maybe change to
strconv.ParseBool(strings.ToLower(v))
But the other stuff does not make much sense to me. Because thats bassically what strings.ParseBool() does.
I encountered an issue when trying the project with Cisco XRd devices, and that patch resolves the problem.
Schema validation and parsing
In some cases, the device returns the strings
"true"or"false"instead of the boolean type, and that fixes the problemThe
GetOptionalInstance()is not working in some contexts, while the appropriate flag (present on the same structure) seems to beIsMandatory.Sending appropriate
gNMI updateanddeleterequestsThe current implementation doesn't take into account the presence of schema in different namespaces, needed in the Cisco environment.
So, there is these needs:
namespace:path) instead of using a "blank" path and only a "value"The proposed implementation is tailored to my environment, and has some more work to do to be ready for every scenario. I leave the code so that it can be taken to understand better the needs:
json_ietf, so I put here my code, but probably it should be moved somewhere elsedeletescenario I used an approach that can understand even path differentiations in subpaths of any grade, while in theupdateone it can understand only the first and second elements of the path (e.g.router/staticbelongs to the modulestatic-routing, whilerouter/ospfbelongs todynamic-routing, so the respective requests should be directed tostatic-routing:router/staticanddynamic-routing:router/ospf)