search

SUSE / supportconfig-utils

Utilities for analyzing supportconfig tarballs
7 stars 7 forks source link

Needs a proper plugin system #3

Open aspiers opened 5 years ago

aspiers commented 5 years ago

We need to figure out a good extensible plugin system which would allow support for different SUSE products to be plugged in without interfering with each other. Currently SOC support is hardcoded into the main supportconfig-tmux script.

One key design goal should be auto-detection, so that the script can figure out whether a supportconfig comes from, say, a SUSE OpenStack Cloud (SOC) Crowbar admin node, or a SUSE Manager node, or a SLE HA cluster node, and so on.

So the plugin system should allow each plugin to implement some code which looks for types of nodes it recognises, and then tells the core system what type it has recognised, if any. It should probably even allow co-existence of multiple types. For example a SOC controller node is also a SLE HA cluster node. So if you want to diagnose a supportconfig from such a node, maybe you want to diagnose the SOC side, or the cluster side, or maybe both. The UI could give the user the choice in these cases.

Finally, the main scripts at the heart of the repo are shell, and Ruby is used for some of the helper scripts. There are advantages to switching everything to a single language (preferably not shell which is a terrible language), but that might also discourage some people from contributing support for the SLE products they work on. So another option we should consider is a language-agnostic interface (e.g. the core talks to the plugins purely via pipes / sockets / other IPC mechanism).

Any feedback or help with any of this is very welcome!

jvanz commented 5 years ago

Hi!

I believe I finally can start to work adding some commands for CaaSP product. Actually, I've already have some python script which I use to extract very simple data. I think it would be nice to integrate those scripts in the project. Is this package still active?

aspiers commented 5 years ago

It's active if people like you contribute to it ;-)

jvanz commented 5 years ago

I would like to understand better why we need to make the plugin talk with the core scripts. I wanna know what you have in mind. As far as I can see, the current state of the project is that we have a some core scripts which setup a tmux session and there are some other scripts which process the files from supportconfig and configure lnav for a better log visualization. That's cool!

What is not clear to me, is why we need a way to communicate between core scripts and plugin ones.

aspiers commented 5 years ago

Isn't this explained in the issue description above? It doesn't make sense to dump a load of product-specific code in the core (e.g. one giant shell script which keeps growing each time someone adds support for a new product) because that would create a horrible mess. And anyway each product group might want to use different languages for their plugin.

However please note that all plugins could exist within this repo. It's just a question of cleanly separating product-specific code from the core. It doesn't need to be complicated.

jvanz commented 5 years ago

I don't mean to have a giant script for all products. What is not clear to me is why the core script needs to know which product the supportconfig come from. Once the tmux session is ready, the users just can call the command they want. Is not just a matter of install the commands in the machine path ? Or do you plan do some automated analysis?

I don't know if you get my point... let me know if it's not clear

aspiers commented 5 years ago

@jvanz commented on November 6, 2019 5:23 PM:

What is not clear to me is why the core script needs to know which product the supportconfig come from.

It doesn't, it's the job of the plugins to figure that out.

Once the tmux session is ready, the users just can call the command they want.

No, the whole point of this is to reduce the amount of manual work required by the user.

Is not just a matter of install the commands in the machine path ? Or do you plan do some automated analysis?

I don't just plan it - it already happens :-) That's the whole point of this project. But currently only for SOC. If you haven't already, I strongly recommend watching the video of the Lunch & Learn:

https://w3s.nue.suse.com/training/2019/L&L_Supportconfig-utils%20&%20lnav/

At 22:19 you can see the automated analysis kick in.