[Improvement] Refactor K8sTshark module #2087
Assignees
Labels
enhancement
New feature or request
Comments
svteb
added a commit
to svteb/testsuite
that referenced
this issue
Jul 1, 2024
Refs: cnti-testcatalog#2072 cnti-testcatalog#2087 - Prior functionality was bound to fixed time of execution (120s), which introduced problems in testing (tshark session ending before the test began). - New functionality mainly implements infinite tshark execution along with the possibility of terminating it when deemed appropriate. This is complemented with robust error handling and termination of the tshark process on unexpected crashes during initialization. NOTE: The main tests currently do not handle states where a crash could occur elsewhere and thus a hanging tshark session can still happen (although unlikely). - The module is properly commented which should allow the user to get a quick understanding of its functionality. - The user functionality remains the same with easier-to-comprehend function names. - Handling of PIDs is rather problematic due to the nature of exec_by_node_bg function, which does not return the PID of the tshark process but rather the PID of the shell executing it (unverified). This is why the retrieval of PID may seem rather complicated (especially the pid_command variable). Possible solutions are listed in a comment, but these don't quite work for various reasons (globbing issues, return of incorrect PID, etc.). As for the kill -15 and kill -9 repetition, some tshark session would get stuck in a zombie state if the commands were not executed in this order. Signed-off-by: svteb <slavo.valko@tietoevry.com>
20 tasks
svteb
added a commit
to svteb/testsuite
that referenced
this issue
Jul 4, 2024
Refs: cnti-testcatalog#2072 cnti-testcatalog#2087 - Prior functionality was bound to fixed time of execution (120s), which introduced problems in testing (tshark session ending before the test began). - New functionality mainly implements infinite tshark execution along with the possibility of terminating it when deemed appropriate. This is complemented with robust error handling and termination of the tshark process on unexpected crashes during initialization. NOTE: The main tests currently do not handle states where a crash could occur elsewhere and thus a hanging tshark session can still happen (although unlikely). - The module is properly commented which should allow the user to get a quick understanding of its functionality. - The user functionality remains the same with easier-to-comprehend function names. - Handling of PIDs is rather problematic due to the nature of exec_by_node_bg function, which does not return the PID of the tshark process but rather the PID of the shell executing it (unverified). This is why the retrieval of PID may seem rather complicated (especially the pid_command variable). Possible solutions are listed in a comment, but these don't quite work for various reasons (globbing issues, return of incorrect PID, etc.). As for the kill -15 and kill -9 repetition, some tshark session would get stuck in a zombie state if the commands were not executed in this order. Signed-off-by: svteb <slavo.valko@tietoevry.com>
svteb
added a commit
to svteb/testsuite
that referenced
this issue
Jul 9, 2024
Refs: cnti-testcatalog#2072 cnti-testcatalog#2087 - Prior functionality was bound to fixed time of execution (120s), which introduced problems in testing (tshark session ending before the test began). - New functionality mainly implements infinite tshark execution along with the possibility of terminating it when deemed appropriate. This is complemented with robust error handling and termination of the tshark process on unexpected crashes during initialization. NOTE: The main tests currently do not handle states where a crash could occur elsewhere and thus a hanging tshark session can still happen (although unlikely). - The module is properly commented which should allow the user to get a quick understanding of its functionality. - The user functionality remains the same with easier-to-comprehend function names. - Handling of PIDs is rather problematic due to the nature of exec_by_node_bg function, which does not return the PID of the tshark process but rather the PID of the shell executing it (unverified). This is why the retrieval of PID may seem rather complicated (especially the pid_command variable). Possible solutions are listed in a comment, but these don't quite work for various reasons (globbing issues, return of incorrect PID, etc.). As for the kill -15 and kill -9 repetition, some tshark session would get stuck in a zombie state if the commands were not executed in this order. Signed-off-by: svteb <slavo.valko@tietoevry.com>
svteb
added a commit
to svteb/testsuite
that referenced
this issue
Jul 9, 2024
Refs: cnti-testcatalog#2072 cnti-testcatalog#2087 - Prior functionality was bound to fixed time of execution (120s), which introduced problems in testing (tshark session ending before the test began). - New functionality mainly implements infinite tshark execution along with the possibility of terminating it when deemed appropriate. This is complemented with robust error handling and termination of the tshark process on unexpected crashes during initialization. NOTE: The main tests currently do not handle states where a crash could occur elsewhere and thus a hanging tshark session can still happen (although unlikely). - The module is properly commented which should allow the user to get a quick understanding of its functionality. - The user functionality remains the same with easier-to-comprehend function names. - Handling of PIDs is rather problematic due to the nature of exec_by_node_bg function, which does not return the PID of the tshark process but rather the PID of the shell executing it (unverified). This is why the retrieval of PID may seem rather complicated (especially the pid_command variable). Possible solutions are listed in a comment, but these don't quite work for various reasons (globbing issues, return of incorrect PID, etc.). As for the kill -15 and kill -9 repetition, some tshark session would get stuck in a zombie state if the commands were not executed in this order. Signed-off-by: svteb <slavo.valko@tietoevry.com>
martin-mat
pushed a commit
that referenced
this issue
Jul 9, 2024
…2097) Refs: #2072 #2087 - Prior functionality was bound to fixed time of execution (120s), which introduced problems in testing (tshark session ending before the test began). - New functionality mainly implements infinite tshark execution along with the possibility of terminating it when deemed appropriate. This is complemented with robust error handling and termination of the tshark process on unexpected crashes during initialization. NOTE: The main tests currently do not handle states where a crash could occur elsewhere and thus a hanging tshark session can still happen (although unlikely). - The module is properly commented which should allow the user to get a quick understanding of its functionality. - The user functionality remains the same with easier-to-comprehend function names. - Handling of PIDs is rather problematic due to the nature of exec_by_node_bg function, which does not return the PID of the tshark process but rather the PID of the shell executing it (unverified). This is why the retrieval of PID may seem rather complicated (especially the pid_command variable). Possible solutions are listed in a comment, but these don't quite work for various reasons (globbing issues, return of incorrect PID, etc.). As for the kill -15 and kill -9 repetition, some tshark session would get stuck in a zombie state if the commands were not executed in this order. Signed-off-by: svteb <slavo.valko@tietoevry.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
The module currently holds 3 distinct functions, each having a duplicate with 1~ line changed. These duplicates should be revised.
Describe the solution you'd like
Create more sensible interfaces. Shorten the code and remove the duplicates. Currently the problem with the module is dependency on uncertain wait times (120 seconds for tshark capture). A function that would terminate tshark capture after its begun would be very helpful.
Additional context
The module is currently used only by suci and oran tests, thus not much code will need to be rewritten outside the module.
The text was updated successfully, but these errors were encountered: