[
https://issues.apache.org/jira/browse/UNOMI-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerome Blanchard updated UNOMI-919:
-----------------------------------
Description:
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 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.
h3. 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).
* Update docker and sample docker compose to take into consideration that new
variable
* Update documentation
h3. 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'
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 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.
h3. Proposal 3
- Remove delegator in health check module and restore each provider as a
classic health-check 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 heath-check feature to split into 2 ones (one for each persistence
type)
- Adapt distribution feature to include the right health-check feature.
was:
## 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.
> 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
> Priority: Major
> Fix For: unomi-3.1.0
>
>
> 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 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.
> h3. 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).
> * Update docker and sample docker compose to take into consideration that
> new variable
> * Update documentation
> h3. 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'
> 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 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.
> h3. Proposal 3
> - Remove delegator in health check module and restore each provider as a
> classic health-check 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 heath-check feature to split into 2 ones (one for each persistence
> type)
> - Adapt distribution feature to include the right health-check feature.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
