Skip to content

Conversation

@lukas-vlcek
Copy link
Contributor

@lukas-vlcek lukas-vlcek commented Jun 26, 2023

Description

I realized that plugin names are note represented correctly according to plugin configuration in testing framework.

Please see the code in this PR for more details.

This PR is not meant to be merged, it is to demonstrate the issue.

More specifically, in tests based on OpenSearchIntegTestCase (ie, number of nodes and their configuration is variable) I can not expect that following code to work correctly:

NodesInfoResponse response = client().admin().cluster().prepareNodesInfo().clear().addMetric("plugins").get();
for (NodeInfo ni : response.getNodes()) {
      assertEquals(
              1,
              ni.getInfo(PluginsAndModules.class).getPluginInfos().stream().filter(
                      pluginInfo -> pluginInfo.getName().equals("rename")
              ).count()
      );
}

It turns out that on some nodes the plugin returns its classname as a value of the getName();

Maybe it is a consequence of how individual nodes and plugins are deployed into cluster in testing framework. However, it came as a surprise to me.

Issues Resolved

As of writing I am not aware of any opened issue. It may not be an issue if this is the design on testing framework (however, it is not documented).

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@dblock
Copy link
Member

dblock commented Jun 28, 2023

So the built-in plugins have this problem? Should we open an issue in OpenSearch and do some renaming on main?

@lukas-vlcek
Copy link
Contributor Author

@dblock I do not think this is a problem of built-in plugins per-se.

I think the issue here is that the OpenSearch testing framework that is in charge of setting up the testing cluster and deploying plugins do something exceptional in some cases:

One example is the plugin name value (as demonstrated by this PR). On one node this plugin has expected name (rename) on the other node this very same plugin has its name equal to its classname.

@dblock
Copy link
Member

dblock commented Jun 30, 2023

I see. What do you propose to fix it?

@lukas-vlcek
Copy link
Contributor Author

I think we need to understand where is this happening and what is the reasoning behind this. I assume the impact/risk is fortunately quite limited. I can imagine we can then put some clarification into testing documentation (assuming there is not much to fix on the code level).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants