Is your feature request related to a problem?
Allow decoupling the integration code from the integration content, we need a clear and clean and way for separation the integration framework code and the actual integration content.
This way should also allow dynamic loading of updated revision of the catalog for an existing opensearch-dashboard service.
This separation should allow to dynamically load a catalog both on plugin loading time and also with a user selection button.
What solution would you like?
The following steps should be implemented:
add an env param that links to a local file directing to the catalog zip file residing somewhere on the local disk as part of the plugin's resources folder (or network location for open network cases)
create a GitHub Action to copy the latest catalog release artifacts into the build process and attach the artifact in the local plugin resources folder
as part of the loading of the plugin it will search the env var and load the catalog locally (or remotely if possible)
Version conflict resolution should apply for uploading catalog integrations templates if such exist on the customer's .kibana index
dblock
commented
1 month ago
Is your feature request related to a problem? Allow decoupling the integration code from the integration content, we need a clear and clean and way for separation the integration framework code and the actual integration content. This way should also allow dynamic loading of updated revision of the catalog for an existing opensearch-dashboard service. This separation should allow to dynamically load a catalog both on plugin loading time and also with a user selection button.
What solution would you like? The following steps should be implemented:
.kibanaindexDo you have any additional context?