Jerome Blanchard created UNOMI-919:
--------------------------------------
Summary: 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
Fix For: unomi-3.1.0
## Context
Regarding PR about [OpenSearch
integration](https://github.com/apache/unomi/pull/715) some changes have been
introduced :
## 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 introduce 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 persistence configure
Thus, UNOMI can be started with either one persistence option or the other
(elasticsearch or opensearch) just with 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 very confusing for a new user that start by running UNOMI using
>docker.
In that mind, we think that the peristence backend should not be a start
parameter but a setup option. Also, using an OSGI configuration holding a map
of existing startup features introduce a custom way of doing something that can
be done using an existing and more standard : a karaf feature.
### Proposal 1
Restore the UNOMI_AUTO_START env variable to its previous behavior and to
introduce a new env variable UNOMI_DISTRIBUTION that will holds the feature set
name that correspond to the desired backend (unomi-distribution-elasticsearch
or unomi-distirbution-opensearch).
### Proposal 2
- Add a `setup` command aside 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 whole
UNOMI instance life cycle. An 'overwrite' option will allow to call unomi:setup
again to change the distribution if needed but the default behavior will forbid
to setup 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 a OSGI config file to
feed the UnomiManagementService, we propose to use a classic feature allowing
the ManagementService to retrieve all the dependencies and start them one by
one as previously done. More than a simple list of string, an xml feature file
will allows also to take into consideration sub features version. And the
distribution descriptor could be then deployed in any maven repository instead
of in a local config file allowing custom production distribution feature
assembly to be easily used into an generic UNOMI package.
- Adapt docker and packages to takes into consideration the UNOMI_DISTRIBUTION
setup variable
- Use a default UNOMI_DISTRIBUTION with elasticsearch as search engine
- Use 2 features to hold the list of startFeatures in a dedicated module called
'distribution'
## 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 mecanism to activate only a subset of
existing providers. We propose to define 2 healthcheck feature (one for each
peristence type) that will hold a specific config file with predifined
providers list. We will then remove the delegator to stay on the previously
activate/deactivate by configuration usage.
Each distribution will them include the corresponding healthcheck feature with
the correct providers activation list already defined.
### Proposal 3
- Remove delegator in healtch check module and restore each provider as a
classic healthcheack provider
- For elasticsearch and opensearch provider, add a check in the init() method
to avoid building client when the provider is not activated in the config.
- Adapt heathcheck feature to split into 2 ones (one for each peristence type)
- Adapt distribution feature to include the right healthcheck feature.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
