📞📱☎️📡🌐 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
Describe the bug
While running the database persistence spec test I ran into a rather unexpected bug with the TarClient module. The CNFManager.export_published_chart function uses this construct:
This causes the tar module to fail in case multiple versions of a helm chart archive are present in the testsuite directory.
To best describe the issue, let me provide you with an example. suppose the mysql sample cnf is going to be deployed, the TarClient module executes the following command to export the chart to the necessary folder in /cnfs/mysql/exported_chart:
tar -xvf mysql-*.tgz -C /cnfs/mysql/exported_chart ~>
tar -xvf mysql-9.0.1.tgz mysql-10.1.1.tgz mysql-10.1.2.tgz ... -C /cnfs/mysql/exported_chart
Supposing there are multiple mysql-*.tgz helm charts in the testsuite directory the tar command fails.
To Reproduce
I believe this issue might affect other spec tests/maybe even the main program, but I've only noticed it with the database_persistence spec test:
export LOG_LEVEL=debug
cd testsuite
touch mysql-x.y.z.tgz or cp the actual mysql helm chart and rename it
crystal spec spec/workload/state_spec.cr:43 | tee results/database_persistence.txt # database persistence spec test
During the program runtime you should be capable of seeing that the /cnfs/mysql/exported_chart directory is not populated with files from the helm chart. The fact that the mysql statefulset successfully deploys is not indicative of this not being an error.
The test fails, upon observing the results/database_persistence.txt file you may see log outputs like this:
I, [2024-04-04 08:10:48 +00:00 #1788708] INFO -- cnf-testsuite: TarClient.untar current directory: /home/ubuntu/testsuite
I, [2024-04-04 08:10:48 +00:00 #1788708] INFO -- cnf-testsuite: TarClient.untar command: tar -xvf mysql-*.tgz -C /home/ubuntu/testsuite/cnfs/mysql/exported_chart
I, [2024-04-04 08:10:48 +00:00 #1788708] INFO -- cnf-testsuite: TarClient.untar output:
I, [2024-04-04 08:10:48 +00:00 #1788708] INFO -- cnf-testsuite: TarClient.untar stderr: tar: mysql-10.1.25.tgz: Not found in archive
tar: Exiting with failure status due to previous errors
Expected behavior
There should be some better mechanism to get the full archive name than file globbing on command line. I believe this could be somehow stored in the existing args/config variable that is being propagated around all the functions that work in this chain of deployment (view task "cnf_setup" and CNFManager.sample_setup) or the export_published_chart function could have some better logic to select a specific archive name.
Once this issue is address how will the fix be verified?
Regardless of how many archives of some cnf will be present in the testsuite directory, one of them will be exported (based on some logic that is to be implemented).
Additional context naggingTarClient module (as well as all other modules) should raise an exception in case some vital command-line execution fails and this should somehow be handled in the code. But that is a different debate.
Describe the bug While running the
database persistence
spec test I ran into a rather unexpected bug with theTarClient module
. TheCNFManager.export_published_chart
function uses this construct:This causes the tar module to fail in case multiple versions of a helm chart archive are present in the
testsuite
directory.To best describe the issue, let me provide you with an example. suppose the mysql sample cnf is going to be deployed, the
TarClient module
executes the following command to export the chart to the necessary folder in/cnfs/mysql/exported_chart
:Supposing there are multiple mysql-*.tgz helm charts in the
testsuite
directory the tar command fails.To Reproduce
I believe this issue might affect other spec tests/maybe even the main program, but I've only noticed it with the
database_persistence
spec test:export LOG_LEVEL=debug
cd testsuite
touch mysql-x.y.z.tgz
orcp
the actual mysql helm chart and rename itcrystal spec spec/workload/state_spec.cr:43 | tee results/database_persistence.txt # database persistence spec test
/cnfs/mysql/exported_chart
directory is not populated with files from the helm chart. The fact that the mysql statefulset successfully deploys is not indicative of this not being an error.results/database_persistence.txt
file you may see log outputs like this:Expected behavior There should be some better mechanism to get the full archive name than file globbing on command line. I believe this could be somehow stored in the existing
args/config
variable that is being propagated around all the functions that work in this chain of deployment (viewtask "cnf_setup"
andCNFManager.sample_setup
) or theexport_published_chart
function could have some better logic to select a specific archive name.Once this issue is address how will the fix be verified?
Regardless of how many archives of some cnf will be present in the
testsuite
directory, one of them will be exported (based on some logic that is to be implemented).Additional
contextnaggingTarClient module
(as well as all other modules) should raise an exception in case some vital command-line execution fails and this should somehow be handled in the code. But that is a different debate.