cnti-testcatalog / testsuite

πŸ“žπŸ“±β˜ŽοΈπŸ“‘πŸŒ 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
https://wiki.lfnetworking.org/display/LN/Test+Catalog
Apache License 2.0
169 stars 70 forks source link

The single process type check is skipped if the AUT is deployed in a non-default namespace #2030

Closed sysarch-repo closed 3 weeks ago

sysarch-repo commented 1 month ago

Describe the bug The single process type check is skipped if the AUT is deployed in a non-default namespace. Some kubectl commands triggered during the check do not observe the namespace, i.e. the -n part is missing. Example for a deployment with two pods - drouter (statefulSet) and dserver (deployment):

I, [2024-05-15 21:12:33 +00:00 #157756]  INFO -- cnf-testsuite: KubectlClient::Get.resource command: kubectl get Deployment dns-dserver -o json
D, [2024-05-15 21:12:34 +00:00 #157756] DEBUG -- cnf-testsuite: KubectlClient::Get.resource output:
I, [2024-05-15 21:12:34 +00:00 #157756]  INFO -- cnf-testsuite: KubectlClient::Get.resource stderr: Error from server (NotFound): deployments.apps "dns-dserver" not found

I, [2024-05-15 21:12:42 +00:00 #157756]  INFO -- cnf-testsuite: KubectlClient::Get.resource command: kubectl get StatefulSet dns-drouter -o json
D, [2024-05-15 21:12:43 +00:00 #157756] DEBUG -- cnf-testsuite: KubectlClient::Get.resource output:
I, [2024-05-15 21:12:43 +00:00 #157756]  INFO -- cnf-testsuite: KubectlClient::Get.resource stderr: Error from server (NotFound): statefulsets.apps "dns-drouter" not found

To Reproduce Steps to reproduce the behavior:

$ cnf-testsuite version CNF TestSuite version: v1.2.0

  1. Run the test with helm_install_namespace set to a non-default namespace, e.g. helm_install_namespace: cnti
  2. Observe the result: 🎬 Testing: [single_process_type] ⏭️ πŸ†SKIPPED: [single_process_type] Container resources not checked βš–πŸ‘€

Expected behavior The check is executed and either succeeds or fails.

Device (please complete the following information): Linux ip-10-0-33-150 6.5.0-1020-aws #20~22.04.1-Ubuntu SMP Wed May 1 16:10:50 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

How will this be tested? aka Acceptance Criteria (optional)

Additional context Note the check conflicts with the specialized init system check. Example with dumb-init: 🎬 Testing: [single_process_type] resource: {kind: "StatefulSet", name: "dns-drouter", namespace: "default"}, pod dns-drouter-0 and container: drouter has more than one process type (/usr/local/bin/dumb-init--/usr/local/bin/dns-app, /usr/local/bin/dns-app) βœ–οΈ πŸ†FAILED: [single_process_type] More than one process type used βš–πŸ‘€

Maybe the single process type should be tolerant to init subsystems (just as a suggestion)

taylor commented 1 month ago

This will probably need to be addressed for all of the specialized init systems. We still want to check for multiple process types when those systems are used, but the init-related process (eg. /usr/local/bin/dumb-init--/usr/local/bin/dns-app) should not be treated as an additional process type causing a failure.

taylor commented 1 month ago

Reference

sysarch-repo commented 1 month ago

@taylor , thanks for your comments. I have probably confused you with providing the additional context (single_process_type check fails if init system is used) that is unrelated to the issue reported. Sorry for that.

The issue concerned in this ticket is that the single_process_type check is skipped if the AUT is deployed in a non-default namespace. Some kubectl commands utilized by the test do not use the -n parameter that needs to be added. Thoughts?

martin-mat commented 1 month ago

@sysarch-repo nice catch.