[
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 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.
was:
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.
> 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 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)
