Feature Request: Outputting the .tar FileName as part of Retina Output please. ☕️

[Tatsinnit]

Is your feature request related to a problem? Please describe.

Can we please get the actual filename printed once Retina CLI distributed Capture command ran successfully. cc: @rbtr and @vakalapa ☕️💡

Issue this will resolve is to the consuming tools which can then use the output and use Kubectl copy to specifically only copy that file to local machine.

So say for example if I have retina run if I get presented with the specific filename I can parse the output and only copy that tar from the node to local host.

Describe the solution you'd like

Can we please get the actual filename printed once Retina CLI distributed Capture command ran successfully.

Describe alternatives you've considered

Alternatively for now I just copy the whole of Capture folder from node to locally, as I presume this tool will not be used beyond diagnostics reasons.

Additional context

[rbtr]

The challenge here is that the timestamp that is appended to the capture name is generated by the capture Job while it is running on the Node itself. So, the CLI doesn't know what that suffix is going to be, especially if you execute it with --no-wait. The rest of the name is discoverable, it's Capture Name - Node Name - (?Timestamp?) .tar.gz.

I think sticking the timestamp on the end of a network capture is pretty standard for this kind of tool where you might be running it over and over and collecting data over time, and I think we should keep that. But maybe the timestamp could be generated by the CLI and passed in to the Job? This means the CLI knows what the tgz filenames will be, and also that they are predictable/consistent across all the Nodes?

There is a minor semantic shift in that the timestamp is the time of request of the capture, and not the true start time of the capture, but the slip should be small...as long as we document those semantics clearly I think it's okay.

[Tatsinnit]

The challenge here is that the timestamp that is appended to the capture name is generated by the capture Job while it is running on the Node itself. So, the CLI doesn't know what that suffix is going to be, especially if you execute it with --no-wait. The rest of the name is discoverable, it's Capture Name - Node Name - (?Timestamp?) .tar.gz.

I think sticking the timestamp on the end of a network capture is pretty standard for this kind of tool where you might be running it over and over and collecting data over time, and I think we should keep that. But maybe the timestamp could be generated by the CLI and passed in to the Job? This means the CLI knows what the tgz filenames will be, and also that they are predictable/consistent across all the Nodes?

There is a minor semantic shift in that the timestamp is the time of request of the capture, and not the true start time of the capture, but the slip should be small...as long as we document those semantics clearly I think it's okay.

Awesome!! @rbtr ☕️🙏 thank you for this detail comment. I am not sure if this is targeted to me, but sharing just 2 cents: 💡💡

• I really like your suggestion/idea because that way CLI can send upfront the name of file which will help greatly (don't know how much the work it will be). You are absolutely bang on money about the challenge with the exactness of (?Timestamp?) .tar.gz is unpredictable so anything which makes it bit easy to locate.

• Re: documentation, hopefully for future sake this discussion could become the point of archive for users to see initial thought-process et. al. :)

• As a minor suggestion/idea: We could also supply custom filenames flag --node-filename and with that flag its responsibility of user / consuming tool to name uniquely otherwise it will over-write the previous file name.

Thank you so much for this. Really appreciate it, sorry if this was target to wider other audience.

[spencermckee]

@Tatsinnit Thanks for the feedback. We can add the capture names to the CLI logs and they can be parsed from there. kubectl cp can be used to rename the files so you can customize the filenames at that point. Would that work for your use case?

[Tatsinnit]

@Tatsinnit Thanks for the feedback. We can add the capture names to the CLI logs and they can be parsed from there. kubectl cp can be used to rename the files so you can customize the filenames at that point. Would that work for your use case?

Thanks @spencermckee for loop back. Cool, just to add more clarity, you mean the filename will be part of the command run output aka CLI log so we can parse it from there? Happy to chat more. Thank you. ☕️❤️

💡 Side note: In the use case, before kubectl cp knowing the filename minimises the obscure nature and just target the specific file to be copied.

i.e. for example: (part of the retina output?)

[spencermckee]

@Tatsinnit Yes, sounds like we're on the same page.