[generate_dump] allow to extend dump with plugin scripts.

[stepanblyschak]

Plugins scripts are placed at /usr/local/bin/debug-dump/ and
the output of these scripts will be gzipped and placed
under dump archive in dump/.gz

Signed-off-by: Stepan Blyshchak [email protected]

- What I did

Added support for tech support extension scripts.

- How I did it

It looks at /usr/bin/debug-dump for scripts, if it finds one it will execute them and save the output to dump/ folder.

- How to verify it

Write a simple scripts that outputs something and place it under /usr/bin/debug-dump/

- Previous command output (if the output of a command-line utility has changed)

- New command output (if the output of a command-line utility has changed)

[stepanblyschak]

retest this please

[bandaru-viswanath]

Looks good to me. It would be great to explicitly call out these 'plugins' as 'dump plugins' or equivalent.

[sujinmkang]

@stepanblyschak what information does this dump plugin try to collect?

[stepanblyschak]

@sujinmkang This mechanism is going to be used by Application Extension infrastructure - https://github.com/stepanblyschak/SONiC/blob/sonic-app-ext-3/doc/sonic-application-extention/sonic-application-extention-hld.md.

This Infra allows to install/upgrade/remove dockers at runtime without image rebuild.
As part of that, those dockers which need to collect additional data during dump generation they would use this mechanism to extend "show techsupport"

[sujinmkang]

PR description says "Plugins scripts are placed at /usr/bin/debug-dump/ and". Isn't it "/usr/local/bin/debug-dump/"?

[sujinmkang]

One more question, even with this dump plugin, I think any new package installed to SONiC can also use the syslog service and write the messages to /var/log/<package_name> directory then 'show tech' can collect that log while it's generating the dump file. What is the purpose of this dump plug for?

[stepanblyschak]

@sujinmkang
Yes, I changed it in PR description.

Logging and dump generation are different things. For my application I generate a dump by executing a command inside docker (lets say this command takes 10 sec). Now, if I don't have this proposed mechanism to extend dump generation I have to continuously print my dump to syslog which has the following issues:

1. I do not know at which point user wants to generate a dump so even if my app continuously prints dump information to syslog I might not catch the right point of time or my daemon can crash and I will lose that information.
2. I produce a lot of load on syslog and on my app causing it to execute a debug dump command all the time
3. Syslog will be bloated with extensions debug output and will distract user from analyzing logs.

[liat-grozovik]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).