[jira] [Updated] (UNOMI-919) Refactor the UNOMI startFeatures configuration to use a Karaf feature
[ 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 Co
[jira] [Updated] (UNOMI-919) Refactor the UNOMI startFeatures configuration to use a Karaf feature
[ 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
[jira] [Updated] (UNOMI-919) Refactor the UNOMI startFeatures configuration to use a Karaf feature
[ 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: 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 introdu
