You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whenever a term is being rendered in the generator, there should be sufficient logging to help debug the translation of .pol to vendor syntax ACLs. This is because Capirca drops incorrect terms, and may process terms in various ways - group terms, or break single terms into multiple terms in order to generate correct vendor syntax.
Informational logs should be present whenever some term being rendered could have clarifying information about why the flow is being rendered in that manner. While Informational logs are used for confirming that things are working as expected, we don't expect these logs to be everywhere, but only when something unexpected or convoluted is occurring.
Warning level logs must be present whenever a term is not being rendered completely. Even if a single protocol in a term with multiple protocols is being skipped, this is considered as a term not being rendered completely, and thus a warning log should be present when this condition is triggered.
Some spots in the current paloalto generator where Warning level logs must be present -
Whenever a term is being rendered in the generator, there should be sufficient logging to help debug the translation of .pol to vendor syntax ACLs. This is because Capirca drops incorrect terms, and may process terms in various ways - group terms, or break single terms into multiple terms in order to generate correct vendor syntax.
Some spots in the current paloalto generator where Warning level logs must be present -
Some spots where informational level logs could be added -
This list is only semi-exhaustive since I may have missed conditions where a warning log may be necessary.
The text was updated successfully, but these errors were encountered: