-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhanced Rule#18 to Disallow YANG LISTs with Over-lapping Keys #1458
Conversation
It is observed that guideline does not describe the rules for YANG list keys. Added rules to make YANG LIST unique.
@dutta-partha @praveen-li pls help review |
@@ -550,12 +562,166 @@ container sonic-interface { | |||
...... | |||
``` | |||
|
|||
#### Example 2: Composite Keys with Same Number of Elements(NOT Allowed case) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one looks right to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean Rule holds good.. And example given makes sense. correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @praveen-li , here is the issue created by @faraazbrcm : sonic-net/sonic-buildimage#16356
The same key count cannot be parsed in GCU side. because two list share the same key count and same key type. When GCU is verifying the YANG model: telemetry_client.yang. GCU failed to parse TELEMETRY_CLIENT_SUB_LIST. It verify the list matches TELEMETRY_CLIENT_DS_LIST then return failure.
I would suggest to use different key count to protect GCU parse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can think of two fix on this:
Combine two list into one with key count=2. Example: https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-bgp-allowed-prefix.yang#L70-L71
Use two different key count to represent these lists. Example: https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/yang-models/sonic-interface.yang#L45-L95
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Composite Keys with Same Number of Elements.
[PC]: Same number of element is allowed by translation. 'Same number of element plus Same type' is not allowed. But if we can support patterns, we can allow same type in future. I feel it should be allowed and should be added in translation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@praveen-li Elements with distinct types but the same number can also lead to overlaps, especially since Redis always treats keys as strings. For instance, the number 123 can also be interpreted as the string '123'. To prevent this, we should apply specific constraints, like patterns for strings and ranges for integer types. This requirement should be clearly stated in the guideline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@praveen-li , in the telemetry client sample, the list defination(TELEMETRY_CLIENT_SUB_LIST
and TELEMETRY_CLIENT_DS_LIST
) belongs to the "same number of element plus Same type". It should not be allowed.
|
||
#### Example 3: Pattern Constraints (Allowed case) | ||
|
||
In this example, `INTERFACE_LIST` uses a key `ifname` that must start with "Eth", while `INTERFACE_IPADDR_LIST` uses a key `ifname` that must start with "Vlan". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the translation support it. Also do we have use case for it? Kindly paste if we have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Translation currently does not support it. Currently the Apps such as sonic-utility, mgmt-common's CVL does not support this translation. But this SONiC YANG contains this scenario. I have raised an issue for sonic-utilities. If this is not supported we need to revert the YANG or accept this guideline to enhance the Apps to support this translation.
I believe we should either develop a SONiC YANG validator that aligns with our guidelines and integrate it into the sonic-buildimage's Makefile to run with each build. This would prevent any unsupported translations. Alternatively, we could enhance the existing YANG test to accept data in CONFIG_DB format instead of YANG format. The test runner would then convert the CONFIG_DB format data to YANG format before executing the test, and any errors encountered should halt the build process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, seems for telemetry client, no config may be added in sample_config_db.json. That's why no build failures. This can be in Guideline to add config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@praveen-li There exists a config for telemetry in sample_config_db.json. Any idea why this has NOT caused the build failure?
|
||
#### Example 6: Length Constraints (NOT Allowed case) | ||
|
||
Here, both `INTERFACE_LIST` and `INTERFACE_ANOTHER_LIST` use a key ifname with overlapping length constraints, making them potentially ambiguous. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have similar commands for examples, 4 to 6. Do we have valid use case right now, where these example or constraints can be used. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no usecase as of today for 4 to 6, but they could become relevant at any time. As I've mentioned, we need to future-proof our applications. One way to do this is by not allowing such YANG lists, which we can enforce through a validator. Additionally, we need to ensure that all YANGs comply with the guidelines. To achieve this, the guidelines must be as clear and explicit as possible, and these points aim to accomplish that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at telemetry YANG, seems there is a genuine case. If yes then.
-- Update Guideline. [please provide real example of today's config].
-- above should be done after translation PR is raised, which supports pattern if primary key has 'same number of element and same type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@praveen-li IMO guideline PR has to go first then the translations. The translations are based on guideline. correct me.
@praveen-li @qiluo-msft @wen587 @faraazbrcm A webex meeting invite is sent to discuss this PR on 9/26 Tues 8:30pm PST, pls plan to join to get a closure. @wen587 I don't have your email contact, I routed the invite thru Qi, pls reachout to Qi for webex info |
@faraazbrcm See this Page https://github.com/sonic-net/sonic-utilities/tree/master Below, Instead of sonic-utilities, build sonic-yang-mgmt PKG. Then you can run tests. Also Note, sonic-yang-mgmt PKG have dependency on sonic-yang-models PKG, so if you change yang models then build sonic-yang-models PKG too.
|
Enhanced PR as per the discussion with YANG subgroup
@faraazbrcm For {yang list with [same number of keys + string type] } In current case, a yang list with [same number of keys + string type] can be allowed. A restriction to include 'pattern of the key' will be added to differentiate. Without pattern keyword for key, translation will not be supported from config_db.json to sonic_yang.json. |
Hi @praveen-li , I want to remind that GCU only supports different keys count for now. That's why the TELEMETRY_CLIENT Yang fails in GCU process. |
Create a PR for Path 2: Do not permit lists to have the same number of keys. |
Hi, @faraazbrcm and @praveen-li , could you help review this PR about Path 2 |
@praveen-li, I've updated this PR in line with Path1, as discussed in subgroup email correspondence with the Alibaba team. I believe we agreed to proceed with Path1, which involves adding support for the pattern statement. Could you please review this PR? If everything looks satisfactory, kindly approve it. If any modifications are needed, please let me know. |
@qiluo-msft add Qi for vis |
As you see in the typical YANG modeling practice like ipv4/ip6, the union type of key node is commonly used in the YANG community like openconfig or ietf. So, in the similar line, the path2 approach would be better versed and structured in YANG modeling. |
@praveen-li @adyeung @yaqiangz we should decide whether to go with path 1 or path 2 ASAP. This PR is aligned with path 1. |
Let's not compromise the effective modeling practices just because of internal implementation constraints in consuming YANG. As we move on, we should be able to encourage SONiC contributors to abstract services in well versed and structured YANG models with a rich set of YANG statements wherever applicable. |
closing because alternate path sonic-net/sonic-buildimage#16861 is accepted |
It is observed that guideline does not describe the rules for YANG list keys. Added rules to make YANG LIST unique.