Skip to content

V2 migration algorithm: add tests for model versions#158697

Merged
pgayvallet merged 6 commits intoelastic:mainfrom
pgayvallet:kbn-xxx-v2-algo-mv-tests
Jun 2, 2023
Merged

V2 migration algorithm: add tests for model versions#158697
pgayvallet merged 6 commits intoelastic:mainfrom
pgayvallet:kbn-xxx-v2-algo-mv-tests

Conversation

@pgayvallet
Copy link
Contributor

Summary

Add integration tests of scenarios using the v2 migration algorithm with SO types that are using the model version API

@pgayvallet pgayvallet added Team:Core Platform Core services: plugins, logging, config, saved objects, http, ES client, i18n, etc t// release_note:skip Skip the PR/issue when compiling release notes Feature:Migrations v8.9.0 labels May 31, 2023
Copy link
Contributor Author

@pgayvallet pgayvallet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Self-review

Comment on lines +67 to +72
if (Object.keys(modelVersionMap).length > 0) {
if (!type.switchToModelVersionAt) {
throw new Error(
`Type ${type.name}: Using modelVersions requires to specify switchToModelVersionAt`
);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed a bug causing the validation to throw if an empty model version map was defined

Copy link
Contributor

@TinaHeiligers TinaHeiligers May 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

@pgayvallet pgayvallet Jun 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 switchToModelVersionsAt is not set

Copy link
Contributor Author

@pgayvallet pgayvallet Jun 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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'],
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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', () => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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', () => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Standard upgrade scenario where the stack version doesn't change (only the model versions of the registered types change)

@pgayvallet pgayvallet marked this pull request as ready for review May 31, 2023 12:53
@pgayvallet pgayvallet requested a review from a team as a code owner May 31, 2023 12:53
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

Copy link
Contributor

@TinaHeiligers TinaHeiligers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@pgayvallet
Copy link
Contributor Author

pgayvallet commented Jun 1, 2023

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 :)

@TinaHeiligers TinaHeiligers self-requested a review June 1, 2023 17:51
Copy link
Contributor

@TinaHeiligers TinaHeiligers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@pgayvallet pgayvallet enabled auto-merge (squash) June 2, 2023 09:33
@kibana-ci
Copy link

💚 Build Succeeded

Metrics [docs]

Unknown metric groups

ESLint disabled line counts

id before after diff
enterpriseSearch 19 21 +2
securitySolution 414 418 +4
total +6

Total ESLint disabled count

id before after diff
enterpriseSearch 20 22 +2
securitySolution 498 502 +4
total +6

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @pgayvallet

@pgayvallet pgayvallet merged commit 1ba8be4 into elastic:main Jun 2, 2023
@kibanamachine kibanamachine added the backport:skip This PR does not require backporting label Jun 2, 2023
@rudolf rudolf added the Epic:ScaleMigrations Scale upgrade migrations to millions of saved objects label Sep 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport:skip This PR does not require backporting Epic:ScaleMigrations Scale upgrade migrations to millions of saved objects Feature:Migrations release_note:skip Skip the PR/issue when compiling release notes Team:Core Platform Core services: plugins, logging, config, saved objects, http, ES client, i18n, etc t// v8.9.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants