Preflight mode without datanode ends up with IllegalStateException

todvora commented 10 months ago

If the user opens the preflight configuration for the first time and decides to "resume startup" without configuring any datanodes, the app, due to IndexerDiscoveryProvider, triggers IllegalStateException.

Expected Behavior

Before datanode and preflight, the default behaviour was to use whatever listens on http://127.0.0.1:9200 if the user does not configure anything else.

Current Behavior

We don't discover any datanodes but we see that the user finished the preflight (PreflightConfigResult.FINISHED), so we asume the datanode path and fail immediately.

Possible Solution

Persist the PreflightConfigResult.SKIPPED if user decides to resume startup without any datanodes
Warn user that resuming startup will require either a datanode instance or explicitly configured indexer in the config file

Steps to Reproduce (for bugs)

Start opensearch on localhost:9200
Start fresh GL server
Open the preflight interface
Don't change anything, click resume startup

Context

Your Environment

Graylog Version:
Java Version:
OpenSearch Version:
MongoDB Version:
Operating System:
Browser version:

moesterheld commented 10 months ago

The same applies if you click "resume startup" without provisioning available data node(s). In this case, the problem is even worse because the only way to resolve it afterwards is to set the enable_preflight_web flag which has to be removed after the first startup again.

I think we should add the SKIPPED state. This could be used to determine if the preflight UI should be shown again (SKIPPED && datanodes available) or if the default connection should be used (SKIPPED && no datanodes available)

Alternatively, I would suggest making the text in the confirmation dialog more explicit:

"Are you sure you want to resume startup without a configured Graylog datanode? This requires pointing elasticsearch_hosts in graylog.conf to a running Opensearch or Elasticsearch instance."

Also, I would change the comments in misc/graylog.conf to not specify a default anymore but explain the new mechanism.

Let me know what you would prefer. I will then implement that solution. I am in favor of the first solution

moesterheld commented 10 months ago

Probably, a combination of both of the above would be optimal

kroepke commented 10 months ago

Could we create a backport to 5.2 for this, please?

Graylog2 / graylog2-server