V2 migration algorithm: add tests for model versions#158697
V2 migration algorithm: add tests for model versions#158697pgayvallet merged 6 commits intoelastic:mainfrom
Conversation
| if (Object.keys(modelVersionMap).length > 0) { | ||
| if (!type.switchToModelVersionAt) { | ||
| throw new Error( | ||
| `Type ${type.name}: Using modelVersions requires to specify switchToModelVersionAt` | ||
| ); | ||
| } |
There was a problem hiding this comment.
Fixed a bug causing the validation to throw if an empty model version map was defined
There was a problem hiding this comment.
This will throw for types that haven't switched to models on the currently running version yet. How do we handle that if a type doesn't need a migration when the switch happens? Will we not allow them to fall back to the most recent (non-model) migration?
The specific scenario I'm thinking about is:
- Current kibana version: 8.11
- switchToModelVersionsAt: 8.10
- Most recent type migration implemented at 8.8. ie. The type didn’t need new migrations, only “legacy” ones.
- We import a SO of that type from 8.7. (that's still allowed, right?)
On import, we run through migrations to get the existing object (on 8.7) to the current version (8.11). The object needs to run through the 8.8 migration but 8.8 < 8.10 (when the switch happened) and we don’t have a model version. How do we handle that?
I'm concerned that we're forcing folks to add a model when we force the switch over, even if the switch is postponed. Unless I'm missing something, we should have pre-emptively initialized a no-op as a model when we set the switch version. We didn't in #158267, an oversight?
There was a problem hiding this comment.
This will throw for types that haven't switched to models on the currently running version yet. How do we handle that if a type doesn't need a migration when the switch happens?
No it won't. It's just that it was previously throwing when modelVersions: {} was defined when switchToModelVersionsAt wasn't, and it won't anymore.
You never were forced to define a model version when you switch. It's just that
- you can't register "old" migrations for versions equal or higher to
switchToModelVersionsAt, if set - you can't register modelVersions if
switchToModelVersionsAtis not set
There was a problem hiding this comment.
The object needs to run through the 8.8 migration but 8.8 < 8.10 (when the switch happened) and we don’t have a model version. How do we handle that?
As we were doing previously. The document will be upgraded to 8.8 given it's the latest register migration.
Keep in mind that the document migrator doesn't know or care about model versions. When model versions are registered, internally this part of the code only knows that some 10.x.0 migrations are present, and apply the exact same logic to them as it was previously doing.
FWIW your scenario is the exact same than if a customer was trying to import a 8.4 document into a 8.9 stack where the latest version of the type of the document is 8.6: it will upgrade the doc to 8.6 during import, and set the typeMigrationVersion accordingly to 8.6. So yes, this is already, and still will be, supported.
There was a problem hiding this comment.
it will upgrade the doc to 8.6 during import, and set the typeMigrationVersion accordingly to 8.6. So yes, this is already, and still will be, supported.
Gold to my eyes! Thank you!
There was a problem hiding this comment.
it will upgrade the doc to 8.6 during import, and set the typeMigrationVersion accordingly to 8.6. So yes, this is already, and still will be, supported.
Gold to my eyes! Thank you!
| // see https://github.com/elastic/kibana/pull/130255/ | ||
| preset: '@kbn/test/jest_integration', | ||
| rootDir: '../../../../../../..', | ||
| roots: ['<rootDir>/src/core/server/integration_tests/saved_objects/migrations/group4'], |
There was a problem hiding this comment.
Created a 4th group for the v2 integration tests
|
|
||
| const NB_DOCS_PER_TYPE = 100; | ||
|
|
||
| describe('V2 algorithm - using model versions - stack version bump scenario', () => { |
There was a problem hiding this comment.
Standard upgrade scenario where the stack version changes at the same time as the model versions of the registered types.
|
|
||
| const NB_DOCS_PER_TYPE = 25; | ||
|
|
||
| describe('V2 algorithm - using model versions - upgrade without stack version increase', () => { |
There was a problem hiding this comment.
Standard upgrade scenario where the stack version doesn't change (only the model versions of the registered types change)
|
Pinging @elastic/kibana-core (Team:Core) |
TinaHeiligers
left a comment
There was a problem hiding this comment.
Changes look good and CI's happy.
I want to clarify if we still support running migrations for older documents on import before giving official approval.
See my reply on the thread :) |
💚 Build Succeeded
Metrics [docs]Unknown metric groupsESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @pgayvallet |
Summary
Add integration tests of scenarios using the v2 migration algorithm with SO types that are using the model version API