[PROPOSAL] Discussion for the index name of AD Extension

[owaiskazi19]

What/Why

What are you proposing?

Currently, AD Extension creates a metedata index

ANOMALY_DETECTORS_INDEX = ".opendistro-anomaly-detectors";

As per 3.x version of OpenSearch only the system index should start with .. To resolve this warning we can change the name of the index to opensearch-anomaly-detectors but this will break the backward compatibility.

What problems are you trying to solve?

index name .opendistro-anomaly-detectors starts with a dot '.', in the next major version

Are there any breaking changes to the API

Backward compatibility needs to be handled with this new change of index name.

[dbwiddis]

Is there a way we can create a tool that users can use to migrate/rename their indices in bulk?

[amitgalitz]

I don't have much context for the extensions/sdk work but in OpenSearch currently .opendistro-anomaly-detectors is a system index. For opensearch 3.x with extensions introduced will it no longer be a system index?

[saratvemulapalli]

@owaiskazi19 AD index .opendistro-anomaly-detectors should have already been a system index[1]. This is exactly how security is ensured in AD plugin.

plugins.security.system_indices.enabled: true
plugins.security.system_indices.indices: [".opendistro-alerting-config", ".opendistro-alerting-alert*", ".opendistro-anomaly-results*", ".opendistro-anomaly-detector*", ".opendistro-anomaly-checkpoints", ".opendistro-anomaly-detection-state", ".opendistro-reports-*", ".opendistro-notifications-*", ".opendistro-notebooks", ".opendistro-asynchronous-search-response*"]

[1] https://opensearch.org/docs/latest/security-plugin/configuration/system-indices/

[dbwiddis]

The problem @owaiskazi19 experienced in trying to create an detector with the .opendistro prefix is that while creating the detector was successful, the REST response gave a warning and thus the response object was not populated, so we were unable to process it to send to the user.

WARNING: request [PUT http://localhost:9200/.opendistro-anomaly-detectors] returned 1 warnings: [299 OpenSearch-3.0.0-SNAPSHOT-401c21054bae7a716e5f8394fce425d102c6ee00 "index name [.opendistro-anomaly-detectors] starts with a dot '.', in the next major version, index names starting with...

If there is already a system index permitted with this name, why are we receiving the error warning? Is the wildcard not parsing properly? Is there a way to suppress this warning and generate a valid REST response when we are using a permitted system index?

[dbwiddis]

Log message generated here

Pattern matching being done here

[dbwiddis]

I believe this line is in error:

this.indexPatternAutomaton = new CharacterRunAutomaton(Regex.simpleMatchToAutomaton(indexPattern));

It is only checking the simple (exact) match rather than the index pattern when called here.

Uh, no, that's not the bug :(

But there is a bug. Still digging.

[dbwiddis]

TLDR: I will create a new bug on OpenSearch project to fix this, and then we can close this issue.

[owaiskazi19]

The problem @owaiskazi19 experienced in trying to create an detector with the .opendistro prefix is that while creating the detector was successful, the REST response gave a warning and thus the response object was not populated, so we were unable to process it to send to the user.

WARNING: request [PUT http://localhost:9200/.opendistro-anomaly-detectors] returned 1 warnings: [299 OpenSearch-3.0.0-SNAPSHOT-401c21054bae7a716e5f8394fce425d102c6ee00 "index name [.opendistro-anomaly-detectors] starts with a dot '.', in the next major version, index names starting with...

If there is already a system index permitted with this name, why are we receiving the error warning? Is the wildcard not parsing properly? Is there a way to suppress this warning and generate a valid REST response when we are using a permitted system index?

Thanks @dbwiddis for explaining the issue with more details. @saratvemulapalli as @dbwiddis mentioned warning was not letting us populate the response object. Removing the . from the index name helped.

[dbwiddis]

I think the issue may be that plugins are disabled -- no security plugin which installs that index?

We can specify the system index in opensearch.yml.

[owaiskazi19]

I think the issue may be that plugins are disabled -- no security plugin which installs that index?

We can specify the system index in opensearch.yml.

Should we use opensearch.yml for extensions? I feel like we should keep it for old plugin architecture only. WDYT?

[dbwiddis]

Should we use opensearch.yml for extensions? I feel like we should keep it for old plugin architecture only. WDYT?

Given that this is directly related to the security plugin configuration, we need to keep it where it is until security plugin features are migrated to core. @peternied may have insight on where these settings might live in the future.

[peternied]

To keep moving fast, I'd recommend reusing the existing solution. The index protection features are not expected to see any updates in the planned future.

To look forward, I think all extensions will want ways to persist data that is relevant to the OpenSearch cluster they are interacting with. While 'settings' can represent this, wouldn't it be a nice perk of interacting with OpenSearch that you could use it to store some of an extension's data in the common index format? Maybe extensions should get an index by default that they don't even need to think about the name of, it's provided automatically. What do folks think of making this a feature of extensions - @dbwiddis you think this is work opening an issue?