Allow the repository to search across all namespaces #82863
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
When we first added the ability to find saved objects across spaces, we made the decision to treat the wildcard (
*) namespace as thedefaultnamespace from the repository's perspective. In other words, if a*ever made its way to the repository, we would treat this the same as thedefaultnamespace.For the default distribution, this wouldn't ever happen organically. For the OSS distribution, this would happen for API consumers who explicitly specified the
namespaces=*query parameter.See #67644 (comment) for context around this decision.
This PR changes the behavior of the wildcard, and instead treats this as a true "search across all namespaces". We're making this change in order to support space-aware Machine Learning jobs (#82639). ML has two use cases for this functionality:
Initialization
When Kibana starts up, it needs to know if any ML job saved objects exist. If not, ML performs an initialization process whereby it creates a saved object for each job that exists in ES.
The initially proposed approach relied on querying the kibana index directly, which is undesirable.
With these changes, ML can instead use an instance of the Saved Objects Repository to search for objects across all spaces:
Repair
The
ml-jobsaved objects are merely proxies to the actual job stored in ES. Given this "linked" nature, it's possible for Kibana's representation of available jobs to differ from the actual set of available jobs. The ML Management screen will provide a way to repair this in order to keep the two in sync.In order to effectively repair Kibana's representation of ML Jobs, we need to be able to search across all spaces in order to see if a specific ML job exists within Kibana anywhere.
cc @jgowdyelastic