📞📱☎️📡🌐 Cloud Native Telecom Initiative (CNTI) Test Catalog is a tool to check for and provide feedback on the use of K8s + cloud native best practices in networking applications and platforms
Is your feature request related to a problem? Please describe.
Some issues with k8s_netstat library have been described in #2078. These include long execution time (even longer after #3 hotfix), hard to maintain code and the general fact that the testing method may give false positives/negatives at random.
Further, the netstat library is currently hardwired to work only with a mariadb database, making the entire shared_database task pretty limited in functionality.
Describe the solution you'd like
I propose that we either rework/refactor the library to give it more abstraction (thus making space for other database CNFs to be tested in the future) or drop it completely.
I lean more towards dropping the library as it conceptually relies on unreliable network connections (that may or may not be there when observed). If we were to continue with the network observation strategy we might as well rely on module K8sTshark from testsuite as packets can be more reliably tracked. Another, probably better option, would be to check the logs of the database itself and dig out the connections that have been made from there (to my knowledge mariadb does store these). Regardless of the approach, verifying other database CNFs will require unique filters for each, but this is currently not exactly possible to implement.
Is your feature request related to a problem? Please describe. Some issues with
k8s_netstatlibrary have been described in #2078. These include long execution time (even longer after #3 hotfix), hard to maintain code and the general fact that the testing method may give false positives/negatives at random.Further, the netstat library is currently hardwired to work only with a mariadb database, making the entire
shared_databasetask pretty limited in functionality.Describe the solution you'd like I propose that we either rework/refactor the library to give it more abstraction (thus making space for other database CNFs to be tested in the future) or drop it completely.
I lean more towards dropping the library as it conceptually relies on unreliable network connections (that may or may not be there when observed). If we were to continue with the network observation strategy we might as well rely on
module K8sTsharkfrom testsuite as packets can be more reliably tracked. Another, probably better option, would be to check the logs of the database itself and dig out the connections that have been made from there (to my knowledge mariadb does store these). Regardless of the approach, verifying other database CNFs will require unique filters for each, but this is currently not exactly possible to implement.