-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Elasticsearch service status when ignoring incompatible versions #73798
Comments
Pinging @elastic/kibana-platform (Team:Platform) |
I consider how the status state behaves is part of the public API of the Core. Any behavior changes there would need to be considered a breaking change to the API, so if we were to make any changes in the future, we will need to consider how it is currently being used. Once/if Core ever has API stability guarantees, we'd need to defer changes to this status check until a major version upgrade. If there is consensus on that premise, then I think Spaces can directly depend on how the
This is a good question, and I think it makes sense to not be in a |
I ran into this in a different scenario while testing Run Kibana with next ES (version +1) cc @LeeDr Initial configuration:
Configuration where I ran into trouble:
|
The
elasticsearch
core service has three service status levels defined today:critical
This happens when Kibana has connected to a cluster which has one or more nodes with incompatible versions.
degraded
This happens when Kibana has connected to a cluster which has one or more nodes with incompatible versions, and Kibana is configured with
elasticsearch.ignoreIncompatibleVersions: true
. This is a dev-only setting which allows Kibana to start up even if it's connected to an incompatible cluster.available
This happens when Kibana has connected to a cluster with fully compatible nodes.
The Spaces plugin waits for
elasticsearch
to becomeavailable
before attempting to create the default space:kibana/x-pack/plugins/spaces/server/default_space/default_space_service.ts
Lines 74 to 82 in bf04235
This works for pretty much everyone, but we run into problems when Kibana is configured with
elasticsearch.ignoreIncompatibleVersions: true
, since theelasticsearch
service never reaches theavailable
status when connected to an incompatible cluster.The result is we never create the Default space, which leads to users getting the dreaded
application privileges must refer to at least one resource
error.Given that, I have a couple of questions:
degraded
state? It's hard to know why a service is degraded to know whether or not to attempt a particular action. For this specific service, and specific degradation reason, it makes sense for Spaces to attempt to create the default space, but that's relies on an implementation detail that this is the only reason the service would ever enter thedegraded
state.degraded
state? Or wouldavailable
be more appropriate? This is a genuine question, I'm not sure what the best approach here would be. I could make arguments for both sides.cc @dgieselaar @elastic/kibana-security
The text was updated successfully, but these errors were encountered: