Simplify executing generic checks as part of the connectivity suite #2250
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We may be interested in creating an action also in case we are not strictly running a connectivity check, but for instance checking for error logs or similar (to benefit from progress and error reporting). Yet, in these cases, we don't strictly have a source pod and destination peer, and it doesn't make sense to attempt capturing hubble flows. Hence, let's slightly adapt the Run method to skip this step when the source pod is nil (as it would also otherwise cause a panic). Additionally, let's also not attempt to print the hubble flows if their collection hasn't even been performed, as potentially misleading. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
NewGenericAction mimics the behavior of the already existing NewAction method, but is intended to be used for assertions that are not strictly connectivity checks (e.g., asserting the absence of log errors over multiple pods), hence not associated with any execution pod nor network target). Yet, it still provides improved progress and error reporting compared to just a bare scenario. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
By default, when the connectivity tests suite is run with the --collect-sysdump-on-failure flag, one sysdump is collected for every failing action. Yet, for certain tests this is superfluous, as subsequent ones would not contain any additional information. One example is represented by asserting the absence of log errors over multiple pods, as introducing no state change by itself. Hence, let's provide the possibility of selectively customizing the sysdump collection policy on a per test basis. In addition to the default policy (i.e., one sysdump per failure), it is possible to request capturing only one sysdump for the given test, regardless of the number of failures, or disable sysdump collection altogether for the given test. The sysdump policy applies only when sysdumps have been requested by the user through the above mentioned flag, otherwise they are never collected. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
tklauser
approved these changes
Jan 23, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When developing new connectivity tests, we may be interested in creating an action also in case we are not strictly running a connectivity check, but for instance checking for error logs or similar (to benefit from better progress and error reporting). Let's introduce a
NewGenericActionmethod for such use-cases, as well as the possibility of tuning the sysdump collection policy, as it may be superfluous to collect one sysdump for each failure.Please review commit by commit, and refer to the commit messages for additional details.