+1 For system view.
Good catch Vlad - i think ignite has no eco system around different plugin
installation per nodes, thus i also think that nodeId is redundant. But if
it`s possible to configure cluster with different plugins per node - seems
it need to be discussed.
Kirill,
You are right. It is a real issue when the Ignite log is not available
and
you want to know if an exact plugin was installed.
I don't realize one thing. Is it really useful/possible to have different
plugins on different nodes? I would prefer not to overload the system
view
with a field that is unlikely to be used. If you think about plugin
version
upgrades, it's probably better to control it automatically but not check
it
visually in the view.
In a case where I have two plugins, I expect to have two rows in the
system
view, but if I got your point correctly, you expected 2 * <cluster_size>
entries.
So, I entirely agree with your idea, but I have doubts about whether the
<node ID> field is the healthy one.
On Tue, Jun 16, 2026 at 8:45 PM ткаленко кирилл <[email protected]>
wrote:
Hi all.
I’d like to propose adding a new system view that exposes information
about plugins installed on cluster nodes.
Currently, plugin information is printed to the log only once during
node
startup. In practice, this makes it inconvenient to inspect plugin
details
later.
For example, if someone wants to check which version of a particular
plugin is running on a node, they need to find logs from that node’s
most
recent startup.
This is not very convenient, and in some cases the required logs may
already be unavailable due to log rotation.
I think it would be useful to have a dedicated system view that allows
users to inspect plugin-related information at runtime for all cluster
nodes.
Possible fields could include:
* node ID / consistent ID
* plugin name
* plugin version
* plugin class name
* plugin info // To do this, I propose adding a new method, String
org.apache.ignite.plugin.PluginProvider#info.
Potential benefits:
* easier operational troubleshooting
* simpler verification of plugin versions across the cluster
* no dependency on startup logs
* better observability of node configuration/state
What do you think? Comments, suggestions, or objections?
