[
https://issues.apache.org/jira/browse/UNOMI-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber reassigned UNOMI-919:
---------------------------------
Assignee: Serge Huber
> Refactor the UNOMI startFeatures configuration to use a Karaf feature
> ---------------------------------------------------------------------
>
> Key: UNOMI-919
> URL: https://issues.apache.org/jira/browse/UNOMI-919
> Project: Apache Unomi
> Issue Type: Improvement
> Affects Versions: unomi-3.1.0
> Reporter: Jerome Blanchard
> Assignee: Serge Huber
> Priority: Major
> Fix For: unomi-3.1.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h1. Context
> Regarding PR about [OpenSearch
> integration]([https://github.com/apache/unomi/pull/715]) some changes have
> been introduced :
> h2. UNOMI_AUTO_START environment variable semantic modification and search
> engine configuration
> Its usage have been modified to add the persistence type configuration
> instead of only true|false option
> A OSGI Config value 'startFeatures' has been introduced to define the feature
> list to install/start according to the keyword passed via AUTO_START variable.
> Healthcheck has introduced a Delegator pattern to use only the provider that
> is relevant regarding the underlying configured persistence.
> Thus, UNOMI can be started with either one persistence option or the other
> (Elasticsearch or OpenSearch) simply using the command unomi:start
> elasticsearch|opensearch
> The existing environment variable UNOMI_AUTO_START (used in Docker, for
> example) is now used to propagate the desired search engine to the final
> Unomi startup command.
> From a developer and test point of view, such flexibility is welcome, but we
> thinks it is confusing for a new user who starts by running UNOMI using
> Docker.
> With that mind, we think that the persistence backend should not be a start
> parameter but a setup option. Also, using an OSGI configuration holding a map
> of existing startup features introduces a custom way of doing something that
> can be done using an existing and more standard : a Karaf feature.
> h3. Proposal 1
> * Restore the UNOMI_AUTO_START env variable to its previous behavior and
> introduce a new env variable, UNOMI_DISTRIBUTION, that will hold the feature
> set name corresponding to the desired backend
> (unomi-distribution-elasticsearch or unomi-distirbution-opensearch).
> * Update Docker and sample docker-compose to take this new variable into
> consideration
> * Update documentation
> h3. Proposal 2
> - Add a 'setup' command alongside start and stop.
> That setup command will take the 'distribution' parameter (previously named
> 'startFeatures') and store it in a global unomi setup config for the entire
> UNOMI instance lifecycle. An 'overwrite' option will allow calling
> unomi:setup again to change the distribution if needed but the default
> behavior will forbid to setting up an already defined distribution to protect
> a production environment from unwanted changes.
> - Use a classic Karaf Feature to describe the 'startFeatures' and call that
> a _distribution_
> Instead of using a comma-separated list of features from an OSGI config file
> to feed the UnomiManagementService, we propose to use a classic feature
> allowing the ManagementService to retrieve all the dependencies of that
> top-level feature and start them one by one, as previously done. More than a
> simple list of string, an XML feature file also allows handling sub-features
> versions. The distribution descriptor could be then deployed in any Maven
> repository instead of a local config file, allowing custom production
> distribution feature assemblies to be easily used in a generic UNOMI package.
> - Adapt Docker and packages to take into consideration the
> UNOMI_DISTRIBUTION setup variable
> - Use a default UNOMI_DISTRIBUTION with Elasticsearch as search engine
> - Use two features to hold the list of startFeatures in a dedicated module
> called 'distribution'
> h2. Introduction of a Delegator in HealthCheck
> To use the correct healthcheck service according to the configured search
> engine, a Delegator pattern ha been introduced.
> Healthcheck service already have a mechanism to activate only a subset of
> existing providers. We propose defining two healthcheck features (one for
> each persistence type) that will hold a specific config file with predefined
> provider lists. We will then remove the Delegator to return to the previously
> activate/deactivate by-configuration approach.
> Each distribution will them include the corresponding healthcheck feature
> with the correct provider activation list already defined.
> h3. Proposal 3
> - Remove the Delegator in the healthcheck module and restore each provider
> as a classic healthcheck provider.
> - For Elasticsearch and OpenSearch providers, add a check in the init()
> method to avoid building the client when the provider is not activated in the
> config.
> - Adapt the heathcheck feature to split into two ones, one for each
> persistence type
> - Adapt the distribution feature to include the appropriate healthcheck
> feature.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
