Pods not coming up after using transport-reactor-netty4 plugin for MCP server

OpenSearch
1

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser): 3.2.0

Describe the issue:

Hi Everyone . I’m trying to enable the inbuilt mcp server option in opensearch. As part of it, i’ve installed the transport-reactor-netty4 plugin in the image. Also set the http.type value in opensearch.yml as mentioned in the official doc (https://docs.opensearch.org/3.0/install-and-configure/configuring-opensearch/network-settings/#selecting-the-transport). But after this, none of the master,client or data pods are coming up complaining about connect_exceptions. Anybody faced the issues/ any solutions for this/

1 Like
2

@pablo Could you take a look into this issue? I have found that the securityadmin.sh is not executed successfully. It is giving the below error:

message: “Running securityadmin script\nSecurity Admin v7\nWill connect to localhost:9200 … done\nERR: An unexpected ResponseException occured: method [GET], host [https://localhost:9200], URI [/_plugins/_security/whoami], status line [HTTP/2.0 403 Forbidden]\nNo security data\nTrace:\norg.opensearch.client.ResponseException: method [GET], host [https://localhost:9200], URI [/_plugins/_security/whoami], status line [HTTP/2.0 403 Forbidden]\nNo security data\n\tat org.opensearch.client.RestClient.convertResponse(RestClient.java:501)\n\tat org.opensearch.client.RestClient.performRequest(RestClient.java:384)\n\tat org.opensearch.client.RestClient.performRequest(RestClient.java:359)\n\tat org.opensearch.security.tools.SecurityAdmin.execute(SecurityAdmin.java:541)\n\tat org.opensearch.security.tools.SecurityAdmin.main(SecurityAdmin.java:154)\n\n\n”

If i remove the http.type value from opensearch.yml, the pods are coming up without issues.

3

@shs_tech I managed to reproduce your issue, it seems the securityadmin.sh is not able to be executed with admin certificates when this setting is turned on. As this feature is still in experimental mode I would recommend to raise a bug report here

In a meantime a possible workaround could be to disable the feature during cluster formation. And enable it after.

2 Likes
4

I am facing the similar issues, How to enable http.type post cluster formation? This is part of the opensearch.yaml and not a cluster setting. Please advise @Anthony

5

@shs_tech @Anthony folks, could please help me with the steps to reproduce the issue:

1. Download and unpack OpenSearch 3.2.0
2. ./bin/opensearch-plugin install transport-reactor-netty4
3. Update opensearch.yml with http.type: reactor-netty4-secure
4. Run OPENSEARCH_INITIAL_ADMIN_PASSWORD=<password> ./opensearch-tar-install.sh
5. Run curl ``https://localhost:9200`` -kv -u admin:<password>

I so far was not able to reproduce it, thank you.

6

@Nagpraveen to enable it post cluster formation, update the opensearch.yml with the http.type configuration.

@reta The issue is when you enable http.type in opensearch and then try to sun securityadmin.sh with cetificates.

2 Likes
7

The issue should be fixed in upcoming 3.3.0 release:

2 Likes
8

@Anthony i am new to OpenSearch, what does “post cluster formation” mean? does it mean create cluster without opensearch.yml first, and manually update opensearch.yml in all nodes (including master, node, ml etc)?

9

@frankz Currently the security index is not able to be initialised if this setting in in opensearch.yml, therefore a workaround can be to start the cluster without this setting in opensearch.yml file, and after the security index is initialised, add the setting to opensearch.yml and restart all the pods.

10

@Anthony it worked with 3.2.*, but after updating the binary to 3.3, getting error to start, a couple of questions

  1. is transport-adapator-netty4 still needed? (is it for sse or both sse and streamable http?)
  2. assuming http.type change is still needed, is this right?

org.opensearch.bootstrap.StartupException: java.lang.IllegalStateException: Unsupported http.type [reactor-netty4]

11

@frankz the plugin seems to be not installed, hence the unknown transport

Also, the issue is fixed in 3.3 release, you should be able to proceed with normal installation proccess.

12

it’s working now with 3.3, what i can see, both are needed

  1. reactor-netty4 plugin
  2. config change: http.type: reactor-netty4
1 Like
13

It’s a clean fix in 3.3 But the basic rule still stands Install the damn plugin before running