APEX-72 Enforce Kibana >= 8.18.0; Remove switchToModelVersionAt#220985
APEX-72 Enforce Kibana >= 8.18.0; Remove switchToModelVersionAt#220985gsoldevila merged 22 commits intoelastic:mainfrom
switchToModelVersionAt#220985Conversation
056a539 to
ee13543
Compare
|
Pinging @elastic/kibana-core (Team:Core) |
switchToModelVersionAtswitchToModelVersionAt; Enforce Kibana >= 8.18.0
|
Pinging @elastic/obs-ux-management-team (Team:obs-ux-management) |
e620ba7 to
f3b9db3
Compare
switchToModelVersionAt; Enforce Kibana >= 8.18.0switchToModelVersionAt
| buildType({ | ||
| name: 'dolly', | ||
| modelVersions: { | ||
| 0: dummyModelVersion(), |
There was a problem hiding this comment.
should we maybe do a runtime check to prevent modelversion 0? Otherwise you can define your type with just mappings and then at a later point define a transform or backfill modelVersion with 0 and I don't think that transform will be applied because the virtualVersionMap with useModelVersionsOnly=false stays 10.0.0.
I think a similar example might be bar with only migrations, if you add a modelVersion 0 then the virtual version still stays 10.0.0 so I think we'd miss mappings_addition.
There was a problem hiding this comment.
Essentially I don't think this test will pass:
expect(
getLatestMappingsModelVersion(
buildType({
migrations: {
'7.17.2': dummyMigration,
'8.6.0': dummyMigration,
}
})
)
).not.toEqual(
getLatestMappingsModelVersion(
buildType({
migrations: {
'7.17.2': dummyMigration,
'8.6.0': dummyMigration,
},
modelVersions: {
0: dummyModelVersionWithMappingsChanges(),
},
})
)
);There was a problem hiding this comment.
I used it as a hack for this test, but fair point, I can try to limit the possible values for the keys.
| switchToModelVersionAt: '8.9.0', | ||
| migrations: { | ||
| '8.9.0': jest.fn(), | ||
| '8.11.0': jest.fn(), |
There was a problem hiding this comment.
Yeah, weird that it was like that 🤷🏼 I'll update it.
8ffb263 to
103cf2f
Compare
… src/core/server/integration_tests/ci_checks'
aaf6256 to
386a784
Compare
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Public APIs missing exports
Unknown metric groupsAPI count
References to deprecated APIs
History
cc @gsoldevila |
…astic#220985) ## Summary * Address elastic#217145 - Put in place a check to ensure we're upgrading from Kibana 8.18.0 or newer. * Address elastic#220521 - New attempt at removing the `switchToModelVersionAt` property, inspired on elastic#219029. The previous attempt caused a regression: index meta information started storing _modelVersions_ that were older than the previously stored ones, which were defaulting to 10.0.0 for SO types that did NOT define `modelVersions`. This was due to the removal of the applyTypeDefaults, which was ensuring all SOs had the `switchToModelVersionAt` property set. This flag was then used by `src/core/packages/saved-objects/base-server-internal/src/model_version/version_map.ts` to determine whether to use `modelVersions` or the legacy `migrations` property in order to determine the latest model version for a given type. When removing the `switchToModelVersionAt` flag (and its default backfill), the logic started defaulting to the latest `migrations` version for those SO types that were not defining any `modelVersion`, resulting in older versions that those stored in the SO indices. This caused incident https://elasticco.atlassian.net/browse/INC-3818. This regression has been shipped in 9.0.0 (the PR was [backported](elastic#219329)), so in top of the cleanup, we now need to address elastic#220521 to ensure a smooth transition _OnPrem => Serverless_. --------- Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Summary
switchToModelVersionAtproperty, inspired on Removed switchToModelVersionAt from SO API definition #219029.The previous attempt caused a regression: index meta information started storing modelVersions that were older than the previously stored ones, which were defaulting to 10.0.0 for SO types that did NOT define
modelVersions.This was due to the removal of the applyTypeDefaults, which was ensuring all SOs had the
switchToModelVersionAtproperty set.This flag was then used by
src/core/packages/saved-objects/base-server-internal/src/model_version/version_map.tsto determine whether to usemodelVersionsor the legacymigrationsproperty in order to determine the latest model version for a given type.When removing the
switchToModelVersionAtflag (and its default backfill), the logic started defaulting to the latestmigrationsversion for those SO types that were not defining anymodelVersion, resulting in older versions that those stored in the SO indices. This caused incident https://elasticco.atlassian.net/browse/INC-3818.This regression has been shipped in 9.0.0 (the PR was backported), so in top of the cleanup, we now need to address #220521 to ensure a smooth transition OnPrem => Serverless.