[Discover][Observability] Register Observability AI Assistant feature #181976
Assignees
Labels
Project:OneDiscover
Enrich Discover with contextual awareness / Merge with Logs Explorer
Team:DataDiscovery
Discover App Team (Document Explorer, Saved Search, Surrounding documents, Graph)
Team:obs-ux-logs
Observability Logs User Experience Team
Projects
Comments
tonyghiani
changed the title
tonyghiani
added
Team:DataDiscovery
|
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
|
Pinging @elastic/obs-ux-logs-team (Team:obs-ux-logs) |
yuliacech
pushed a commit
to yuliacech/kibana
that referenced
this issue
May 3, 2024
…ic#181952) ## 📓 Summary Closes elastic#181528 Closes elastic#181976 **N.B.** This work was initially reviewed on a separate PR at tonyghiani#1. This implementation aims to have a stateful layer that allows the management of dependencies between Discover and other plugins, reducing the need for a direct dependency. Although the initial thought was to have a plugin to register features for Discover, there might be other cases in future where we need to prevent cyclic dependencies. With this in mind, I created the plugin as a more generic solution to hold stateful logic as a communication layer for Discover <-> Plugins. ## Discover Shared Based on some recurring naming in the Kibana codebase, `discover_shared` felt like the right place for owning these dependencies and exposing Discover functionalities to the external world. It is initially pretty simple and only exposes a registry for the Discover features, but might be a good place to implement other upcoming concepts related to Discover. Also, this plugin should ideally never depend on other solution plugins and keep its dependencies to a bare minimum of packages and core/data services. ```mermaid flowchart TD A(Discover) -- Get --> E[DiscoverShared] B(Logs Explorer) -- Set --> E[DiscoverShared] C(Security) -- Set --> E[DiscoverShared] D(Any app) -- Set --> E[DiscoverShared] ``` ## DiscoverFeaturesService This service initializes and exposes a strictly typed registry to allow consumer apps to register additional features and Discover and retrieve them. The **README** file explains a real use case of when we'd need to use it and how to do that step-by-step. Although it introduces a more nested folder structure, I decided to implement the service as a client-service and expose it through the plugin lifecycle methods to provide the necessary flexibility we might need: - We don't know yet if any of the features we register will be done on the setup/start steps, so having the registry available in both places opens the door to any case we face. - The service is client-only on purpose. My opinion is that if we ever need to register features such as server services or anything else, it should be scoped to a similar service dedicated for the server lifecycle and its environment. It should never be possible to register the ObsAIAssistant presentational component from the server, as it should not be permitted to register a server service in the client registry. A server DiscoverFeaturesService is not required yet for any feature, so I left it out to avoid overcomplicating the implementation. ## FeaturesRegistry To have a strictly typed utility that suggests the available features on a registry and adheres to a base contract, the registry exposed on the DiscoverFeaturesService is an instance of the `FeaturesRegistry` class, which implements the registration/retrieval logic such that: - If a feature is already registered, is not possible to override it and an error is thrown to notify the user of the collision. - In case we need to react to registry changes, is possible to subscribe to the registry or obtain it as an observable for more complex scenarios. The FeaturesRegistry already takes care of the required logic for the registry, so that `DiscoverFeaturesService`is left with the responsibility of instantiating/exposing an instance and provide the set of allowed features. --------- Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
📓 Summary
To prevent cyclic dependencies between plugins/packages, we need to create a new extension point for registering an Observability AI Assistant using the extension framework implemented with #181528.
✔ Acceptance Criteria
discover-sharedplugin.The text was updated successfully, but these errors were encountered: