Tags: openconfig/ygot
Tags
Add OverrideLeafList support in ygot diff. (#1046) * Add DeleteWithUpdateLeafList support in ygot diff. Implemented handling for DeleteWithUpdateLeafList operation in diff.go Added corresponding test cases in diff_test.go Tested locally to ensure correct functionality and pushed the generated Diff config in Arista FakeFabric (Google Internal Tool). Details: Explicitly delete and then update leaf-list, which is different and exists in both orig and modified. For example, if the original path is x/y/[a, b] and the modified leaf-list is x/y/[b, c], Then resulting notification will contain: Delete x/y/[a, b] Update x/y/[b, c] If this is false, then the leaf-list will be updated directly to the new value without the delete step. This is required because if the leaf-list is updated directly, the resulting notification will be: Update x/y/[b, c] This will cause the new value to be appended in the OC, but the original value will still be present in the OC. Resultant OC in the device will be x/y/[a, b, c]. * add newline * rename to OverrideLeafList * correct the delete op comment * correct the comment * ignore binary type * fix tests * ignore binary not uint8 * improve code
Add skip_deprecated and skip_obsolete flags to ygot (#1037) * Add SkipDeprecated and SkipObsolete flags to ygot/ygen * Extend to individual deprecated/obsolete leaf fields within containers * Add helper functions isDeprecated(yang.Node) and isObsolete(yang.Node)
Add fields to IR and IROptions used by settting the path origin from … …the YANG module name or a specified name. (#1030) * Add fields to IR and IROptions structs to support ygnmi/generator command option to set the path origin from the YANG module name or an arbitrarily specified name. * fix some indents * fix some indents again * Modify to parse the origin name information during IR generation * Add a test code * move origin name field to YANGNodeDetails * fix test cases in genir_test.go * fix as review comments on May 23rd --------- Co-authored-by: Rob Shakir <[email protected]>
Fix a bug in protoFromPathsInternal function in proto.go causing enca… ( #1028) * Fix a bug in protoFromPathsInternal function in proto.go causing encapsulation header details to be lost when mapping gNMI paths to protobuf fiedls. Root cause: the issue stems from incorrect path construction when recursing into nested messages. Something like this will happen: "DEBUG: recursing into nested message gribi_aft.Afts.NextHop.EncapHeader.mpls, path: elem:{name:"afts"} elem:{name:"next-hops"} elem:{name:"next-hop"} elem:{name:"encap-headers"} elem:{name:"encap-header" key:{key:"index" value:"11"}} elem:{name:"afts"} elem:{name:"next-hops"} elem:{name:"next-hop"} elem:{name:"encap-headers"} elem:{name:"encap-header"} elem:{name:"mpls"}. When findChilren uses these malformed paths to search for nested fields, it returns 0 children because no paths in the input map match this duplicated structure. * Fix a bug in protoFromPathsInternal function in proto.go causing encapsulation header details to be lost when mapping gNMI paths to protobuf fiedls. Root cause: the issue stems from incorrect path construction when recursing into nested messages. Something like this will happen: "DEBUG: recursing into nested message gribi_aft.Afts.NextHop.EncapHeader.mpls, path: elem:{name:"afts"} elem:{name:"next-hops"} elem:{name:"next-hop"} elem:{name:"encap-headers"} elem:{name:"encap-header" key:{key:"index" value:"11"}} elem:{name:"afts"} elem:{name:"next-hops"} elem:{name:"next-hop"} elem:{name:"encap-headers"} elem:{name:"encap-header"} elem:{name:"mpls"}. When findChilren uses these malformed paths to search for nested fields, it returns 0 children because no paths in the input map match this duplicated structure.
🐜: squash bug related to leaf-lists and shadow schemas. (#980) * 🐜: squash bug related to leaf-lists and shadow schemas. * (M) util/reflect.go - Fix missing parameter to string output. * (M) ytypes/{leaf,node,node_test,schema_test,util_schema}.go - Two bugs fixed. 1. In the case that one calls `SetNode` with something that was not a gNMI `TypedValue` and was not JSON, then we could panic when attempting to type cast it. 2. If a schema was generated that uses path compression, and `SetNode` was called for a node that was compressed out, but `PreferShadowPaths` was not set AND this node was a leaf-list then rather than performing a no-op (the expected behaviour, since we asked to set a node that was not the 'preferred' thing to set), then we would bail with an error since the schema was not a leaf schema. Small fix, lots of testing to find the root cause here. * (M) ytypes/schema_test/set_test.go - Bug reproduction. * Remove `TestFish`. 🐠
Fix `Marshal7951` for direct union leaf calls. (#947) When `jsonValue` is called using the output of `reflect.ValueOf()` instead of `reflect.StructField`, any interface type is lost through re-packing to the empty interface (any). This means the `reflect.Kind` of a union field is no longer the union type, but instead its underlying concrete type. The current code doesn't handle this case, leading to runtime errors. This handling code is now added, with a couple more fixes related to `empty` types. ----- Tested manually that the following ygnmi call is no longer affected by the original error: ```go sp := gnmi.OC().NetworkInstance("DEFAULT").Protocol(oc.PolicyTypes_INSTALL_PROTOCOL_TYPE_STATIC, "STATIC") return ygnmi.Replace(context.Background(), c, sp.Static("1.1.1.1/32").SetTag().Config(), oc.NetworkInstance_Protocol_Static_SetTag_Union(oc.UnionUint32(42))) ```
PreviousNext