You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Anomaly Detection (AD) backend is currently being converted from a plugin to an extension. AD runs jobs in the background to monitor indices in a cluster for a detector. In the plugin model, AD serializes the user (including roles and backend roles) upon detector creation and saves it as part of the detector metadata. When it comes time to run the detector, AD performs roles injection to evaluate a dedicated user (called plugin) with the roles stored in the detector’s metadata to determine if the original user could perform the action. This will not work for AD running as an extension.
More generally, outside of the Anomaly Detection use-case, guidance needs to be provided for extensions developers on how to implement extensions that want to interact with the OpenSearch cluster asynchronously. When implementing microservices today, developers will typically configure the OpenSearch client used in the microservice with a username and password that is defined in the internal user list of OpenSearch. This will not work for extensions. The password will never be shared with an extension. An alternative approach to asynchronous jobs needs to be developed.
As a user, my requests to extensions that run background tasks require an identity to execute
Open Question: For anomaly detection as an extension, will the asynchronous tasks be run from nodes within the cluster or will they be run on the extension? How does scheduling work with extensions?
List of tasks to complete to support this feature:
Anomaly Detection (AD) backend is currently being converted from a plugin to an extension. AD runs jobs in the background to monitor indices in a cluster for a detector. In the plugin model, AD serializes the user (including roles and backend roles) upon detector creation and saves it as part of the detector metadata. When it comes time to run the detector, AD performs roles injection to evaluate a dedicated user (called
plugin
) with the roles stored in the detector’s metadata to determine if the original user could perform the action. This will not work for AD running as an extension.More generally, outside of the Anomaly Detection use-case, guidance needs to be provided for extensions developers on how to implement extensions that want to interact with the OpenSearch cluster asynchronously. When implementing microservices today, developers will typically configure the OpenSearch client used in the microservice with a username and password that is defined in the internal user list of OpenSearch. This will not work for extensions. The password will never be shared with an extension. An alternative approach to asynchronous jobs needs to be developed.
See example from the user guide of
opensearch-py
: https://github.com/opensearch-project/opensearch-py/blob/main/USER_GUIDE.md#creating-a-client for configuring a client to connect with a secure cluster.Resolves:
Open Question: For anomaly detection as an extension, will the asynchronous tasks be run from nodes within the cluster or will they be run on the extension? How does scheduling work with extensions?
List of tasks to complete to support this feature:
The text was updated successfully, but these errors were encountered: