Package additional debugging tools in multiple languages

[dotnwat]

It would be useful if we packaged some of our debugging tools so that they were available on a normal redpanda installation. For example this: #2431. As far as the python tools go, they don't really even need to be packaged properly (but that'd be nice) just merely in a predictable location is useful.

[emaxerrno]

I'm not sure this is a good product direction.

The point of doing rpk plugins was exactly to solve this problem. Plugins can be pushed to the rpk plugin registry, installed via rpk plugin install They, however need to be written in Go. is a shame we wrote that in python given that we already have a ton of infrastructure that @twmb already wrote with build publishing, etc.

Moving this to a discussion.

[emaxerrno]

cc: @mmaslankaprv for visibility.

[vsaraswat]

If we want a plugin containing debugging tools that is fine. But if we think a tool is something > 80% users are going to use anyway, making them download the plugin seems to be added friction.

+1 on packaging the most relevant debugging material into rpk debug. That seems like it would make it easiest for a user to find what they need quickly.

[dotnwat]

The point is to use packaging as a vector for distribution. Go, python, etc.. doesn't matter. When what is being distributed are tools that devs/support enigneers use during a support call for example, the alternative is quite a bottleneck.

[dotnwat]

I'm not sure this is a good product direction.

The point of doing rpk plugins was exactly to solve this problem. Plugins can be pushed to the rpk plugin registry, installed via rpk plugin install They, however need to be written in Go. is a shame we wrote that in python given that we already have a ton of infrastructure that @twmb already wrote with build publishing, etc.

Moving this to a discussion.

Python was chosen precisely because it does not require shipping a dev environment to a customer (at least, python is a pretty safe assumption outside alpine docker images), and can be used to make alternations to analysis tasks on the fly since the tools don't have a fixed, predefined set of functionality that can be used to solve problems. If we want to ship the go compiler or some other solution then that is great--it will work. But let's be honest about the downsides of a compiled language in the context these tools are designed to be used in. Another upside is that they exist now, but we don't have them written in Go, yet.

[dotnwat]

I'm not sure this is a good product direction.
The point of doing rpk plugins was exactly to solve this problem. Plugins can be pushed to the rpk plugin registry, installed via rpk plugin install They, however need to be written in Go. is a shame we wrote that in python given that we already have a ton of infrastructure that @twmb already wrote with build publishing, etc.
Moving this to a discussion.

I'm not really sure I see any benefit to re-writing in Go as a pre-req to actually using them to solve problems. The big downside to rewriting in Go is that the Python versions exist today.

Python was chosen precisely because it does not require shipping a dev environment to a customer (at least, python is a pretty safe assumption outside alpine docker images), and can be used to make alternations to analysis tasks on the fly since the tools don't have a fixed, predefined set of functionality that can be used to solve problems. If we want to ship the go compiler or some other solution then that is great--it will work. I think that @twmb had some idea about using a template solution to offer some flexibility without recompiling.

[dotnwat]

We may also want to add things like our python gdb plugins. Or package them in some other way so that they are easily installable on customer sites for debugging / support. not everything fits into rpk debug.

[emaxerrno]

Let’s define a plug-in interface and add it to the rpk plugin system which will verify and install in right paths etc.

[emaxerrno]

We probably need an additional private repo for them

[twmb]

I think more can fit into rpk debug than we think. For anything that we think can't, I'd be pretty curious why. The way I think of it, if something is a great tool for support to debug, why wouldn't that be a great tool for anybody, and why wouldn't it be within rpk?

[dotnwat]

if the plugin system can download arbitrary files onto brokers, then that would solve the issue because a plugin could then fetch a python program, like a GDB plugin. the gdb plugin won't fit into the model of rpk debug because it is an interactive process. i mean, it could start gdb for me but that's about it.

[emaxerrno]

It should download and audit from a registry and with auto completion and a bunch of other goodies.