Skip to content
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

Chopps/oper choice case #15131

Merged
merged 2 commits into from
Jan 11, 2024

Conversation

choppsv1
Copy link
Contributor

Implement missing oper-state choice/case support.

  • When reviewing suggest doing per commit as one of the 2 commits is a rote change.

@choppsv1 choppsv1 force-pushed the chopps/oper-choice-case branch from 79df49c to 7b7725f Compare January 11, 2024 13:51
Copy link
Contributor

@idryzhov idryzhov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have one question.

Comment on lines +116 to 119
"c1value": 21,
"c2cont": {
"c2value": 2868969987
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks wrong that we simultaneously have values from two different cases of a choise in our result. I think it's a violation of the RFC https://datatracker.ietf.org/doc/html/rfc8342#section-5.3. It says about operational datastore:

   Only semantic constraints MAY be violated.  These are the YANG
   "when", "must", "mandatory", "unique", "min-elements", and
   "max-elements" statements; and the uniqueness of key values.

   Syntactic constraints MUST NOT be violated, including hierarchical
   organization, identifiers, and type-based constraints.  If a node in
   <operational> does not meet the syntactic constraints, then it
   MUST NOT be returned, and some other mechanism should be used to flag
   the error.

This seems like a hierarchical organization to me that should not be violated. Should we use lyd_validate_all with LYD_VALIDATE_OPERATIONAL option somewhere at the end to make sure we don't produce an incorrect operational tree?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is on purpose. We should trust the backend to get this right, or it's a bug in the backend. I don't see a reason to extra-police this at the cost of CPU time and complexity.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds fine. We can always add a validation later if we decide that it's necessary. Merging.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did think about the fact that the test case violated the standard, but then figured it was also OK since the testing framework here is too simple and it highlighted the fact that the backend could do this. I have more tests i did locally that we can work back in once we have some implemented models with real choice/case stements. :)

@idryzhov idryzhov merged commit 883f134 into FRRouting:master Jan 11, 2024
9 checks passed
@choppsv1 choppsv1 deleted the chopps/oper-choice-case branch January 12, 2024 08:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants