CTS charts fail to export intact tar archive to report results

[planetf1]

Whilst testing CTS for 3.12 I noticed that the reporting mechanism seems broken

➜  graph kubectl exec -it cts-report-7zlt5 -- sh -c 'cat /export/pipe' | tar -xvf -
Defaulted container "wait-for-retrieval" out of: wait-for-retrieval, wait-for-platform (init), wait-for-kafka (init), wait-for-init (init), report (init)
x export/cts.tar.gz
                   tar: Damaged tar archive
                                           tar: Retrying...
                                                           tar: Damaged tar archive

The CTS itself ran, and REST API calls can extract the detailed report -- and show CTS ran cleanly.

This therefore isn't a series issue with egeria, but it has happened on 2 runs of CTS (within openshift)

[planetf1]

See odpi/egeria#6898

[planetf1]

Confirmed same issue when run locally (rancher desktop)

Will probably need to leave this for now unless you have any ideas @cmgrote ? I don't see it affecting the base, so at worst will add a reference in the release notes to this issue & suggest workaround to retrieve the results via rest api.

[planetf1]

kubectl logs cts-report-ql7js
Defaulted container "wait-for-retrieval" out of: wait-for-retrieval, wait-for-platform (init), wait-for-kafka (init), wait-for-init (init), report (init)
Creating a fifo pipe to send the output data
You'll need to stream the files out for this pod to shutdown, using a command like:
kubectl exec POD_NAME -- sh -c 'cat /export/pipe' | tar -xvf -

kubectl exec -it cts-report-ql7js -- sh -c 'cat /export/pipe' | tar -xvf -
Defaulted container "wait-for-retrieval" out of: wait-for-retrieval, wait-for-platform (init), wait-for-kafka (init), wait-for-init (init), report (init)
command terminated with exit code 255
tar: Error opening archive: Unrecognized archive format

[lpalashevski]

I experienced related but different behavior.

> kubectl exec cts-report-qkxcf -- sh -c 'cat /export/pipe' | tar -xvf -
Defaulted container "wait-for-retrieval" out of: wait-for-retrieval, wait-for-platform (init), wait-for-kafka (init), wait-for-init (init), report (init)
x export/cts.tar.gz

No output file was generated, no error printed on console.

Strangely, the stream was consumed somehow completing the work for "wait-for-retrieval" container and destroying the "cts-report-qkxcf" pod -- as was expected.

Lucky I before executing the pipe command I manually archived the /export files form "wait-for-retrieval" container and did simple 'kubectl cp' to get them out.

kubectl exec -it pod/cts-report-qkxcf -c wait-for-retrieval -- tar -czvf /tmp/export.tar.gz /export
kubectl cp cts-report-qkxcf:/tmp/export.tar.gz -c wait-for-retrieval  ~/Downloads/export.tar.gz

I looks like the pipe export is not reliable way to get the content. I think we should tar the files on cts competition and keep the cts-report pod instance alive so we can retrieve the archive with simple kubectl cp like in the example above.

Alternative is to install python or node micro http server and expose the folder on web port (alternative to building rest api)

My environment is: MacOS 12.6.1, Docker Desktop v4.12, Kubernetes 1.25