[
https://issues.apache.org/jira/browse/UNOMI-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-998:
------------------------------
Description:
h3. Summary
The current migration test starts from a Unomi 1.6 data set, and all Unomi
features are already installed when it runs. Because of this, it did not catch
the problems found when migrating real 3.0 data (UNOMI-996 and UNOMI-997).
Some checks also pass too easily:
* a built-in definition is accepted without checking that it is the 4.0 version,
* the test does not fail when the default tenant is missing,
* the migrated data is only checked on Elasticsearch.
The goal of this ticket is a test that migrates 3.0 data under the same
conditions as the migration guide, and fails when the result is wrong.
h3. Ways to explore
* Add a 3.0.x data set that includes a cluster node index, a Salesforce
connector configuration and geonames data. Build it from made-up data only.
* Run the migration with only the features that are installed at boot.
* Cover OpenSearch where possible.
h3. How to test
The new test fails on the 4.0.0 release candidate. It passes once UNOMI-996 and
UNOMI-997 are fixed. It runs as part of the normal integration test build, so a
future change that breaks the 3.0 upgrade fails the build.
The test must check at least:
* the migration finishes with only the boot features installed,
* the default tenant exists, and the test fails if it does not,
* the built-in definitions in use are the 4.0 versions, not just items with the
right id prefix,
* no user-created item is in the "system" tenant, and every migrated document
has a tenant,
* the cluster node index, the Salesforce configuration and the geonames data
are migrated and readable,
* the API key file written by the migration names the right headers (see
UNOMI-1009),
* a request with the new public key works, and an admin request with the tenant
header sees the migrated data.
was:
h3. Summary
The current migration test starts from a Unomi 1.6 data set, and all Unomi
features are already installed when it runs. Because of this, it did not catch
the problems found when migrating real 3.0 data (UNOMI-996 and UNOMI-997).
Some checks also pass too easily:
* a built-in definition is accepted without checking that it is the 4.0 version,
* the test does not fail when the default tenant is missing,
* the migrated data is only checked on Elasticsearch.
The goal of this ticket is a test that migrates 3.0 data under the same
conditions as the migration guide, and fails when the result is wrong.
h3. Ways to explore
* Add a 3.0.x data set that includes a cluster node index, a Salesforce
connector configuration and geonames data. Build it from made-up data only.
* Run the migration with only the features that are installed at boot.
* Check that built-in definitions are the 4.0 versions, and that the default
tenant exists.
* Check that no user-created item ends up in the "system" tenant.
* Cover OpenSearch where possible.
h3. How to test
The new test fails on the 4.0.0 release candidate. It passes once UNOMI-996 and
UNOMI-997 are fixed.
> Migration tests do not cover an upgrade from Unomi 3.0
> ------------------------------------------------------
>
> Key: UNOMI-998
> URL: https://issues.apache.org/jira/browse/UNOMI-998
> Project: Apache Unomi
> Issue Type: Test
> Reporter: Serge Huber
> Priority: Major
> Fix For: unomi-4.0.0
>
>
> h3. Summary
> The current migration test starts from a Unomi 1.6 data set, and all Unomi
> features are already installed when it runs. Because of this, it did not
> catch the problems found when migrating real 3.0 data (UNOMI-996 and
> UNOMI-997).
> Some checks also pass too easily:
> * a built-in definition is accepted without checking that it is the 4.0
> version,
> * the test does not fail when the default tenant is missing,
> * the migrated data is only checked on Elasticsearch.
> The goal of this ticket is a test that migrates 3.0 data under the same
> conditions as the migration guide, and fails when the result is wrong.
> h3. Ways to explore
> * Add a 3.0.x data set that includes a cluster node index, a Salesforce
> connector configuration and geonames data. Build it from made-up data only.
> * Run the migration with only the features that are installed at boot.
> * Cover OpenSearch where possible.
> h3. How to test
> The new test fails on the 4.0.0 release candidate. It passes once UNOMI-996
> and UNOMI-997 are fixed. It runs as part of the normal integration test
> build, so a future change that breaks the 3.0 upgrade fails the build.
> The test must check at least:
> * the migration finishes with only the boot features installed,
> * the default tenant exists, and the test fails if it does not,
> * the built-in definitions in use are the 4.0 versions, not just items with
> the right id prefix,
> * no user-created item is in the "system" tenant, and every migrated document
> has a tenant,
> * the cluster node index, the Salesforce configuration and the geonames data
> are migrated and readable,
> * the API key file written by the migration names the right headers (see
> UNOMI-1009),
> * a request with the new public key works, and an admin request with the
> tenant header sees the migrated data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
