-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move KibanaMigrator into Server SavedObjectsService #43433
Conversation
cd9ea4d
to
f7cea53
Compare
b70eff5
to
ea6486a
Compare
The behavior here sounds good, though I haven't tested it myself yet. My main questions are related to the Do you know why |
It's just used as a file server as far as I can tell. I find our build system a rather scary black box, so I don't know how much work this would be, but conceptually it feels like we shouldn't need to boot all of Kibana to optimize our frontend bundles or server unit testing bundles, so perhaps there's a way to untangle these from KbnServer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ML changes LGTM
We need to support two behaviours:
Instead of introducing a new The other option would be to decouple this from Core/KbnServer completely and create a lightweight file server that uses the PluginService in a standalone way to collect pluginSpecs and compile the test bundles. @elastic/kibana-operations Do you have any feedback or suggestions? |
Is this ready for review? I noticed some WIP code in the service class: https://github.com/elastic/kibana/pull/43433/files#diff-e77c8c0ea344aeee10b656f96c2a3f4aR123 |
💔 Build Failed |
💔 Build Failed |
const createConfigServiceMock = ({ | ||
atPath = {}, | ||
getConfig$ = {}, | ||
}: { atPath?: unknown; getConfig$?: Record<string, any> } = {}) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with this approach atPath
loses type safety. const configService = configServiceMock.create({ atPath: 1 });
💚 Build Succeeded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless I'm mistaken the only changes you need reviewed by Stack Services are this single line change, right?
If so, LGTM :)
It seems to make sense from the context.
* Rename SavedObjectsService -> SavedObjectsLegacyService * Expose legacy pluginSpecs from Core LegacyService * Expose legacy uiExports from Core LegacyService * Move kibana config to NP * Expose pluginExtendedConfig from LegacyService * Make KibanaMigrator NP compatible * KibanaMigrator -> NP SavedObjectsService * SavedObjectsService never stop retrying ES connection error * Move waiting for migrations to complete till after legacy service start * Fix ESArchiver's KibanaMigrator * Fix reload logging config tests * Run migrations on savedobjects start * Fix env tests * Fix and make legacy tests more robust/isolated * Cleanup code * Fix invalid config test * Fix SavedObject Migrations logging test * SavedObjectsService tests * Lifecycle logging and improve getting kibanaConfig instance * Fix awaitMigration bug and test * Fix typing error * Review comments * Remove unecessary KibanaConfig class * Move legacy plugin config extension, specs, uiExports entirely into Core uiExports, specs, disabledSpecs, config now get injected into KbnServer * Fix config deprecation test * Use existing logger mock * Create SavedObjectsConfig for migration config * Define KibanaMigratorContract type * KibanaMigratorContract -> IKibanaMigrator + docs improvements * Fix esArchiver's KibanaMigrator * Fix plugin generator integration test * ConfigServiceContract -> IConfigService * Address review comments * Review nits * Document migrations.skip config * Review comments continued... * awaitMigrations -> runMigrations * Type improvements
* Rename SavedObjectsService -> SavedObjectsLegacyService * Expose legacy pluginSpecs from Core LegacyService * Expose legacy uiExports from Core LegacyService * Move kibana config to NP * Expose pluginExtendedConfig from LegacyService * Make KibanaMigrator NP compatible * KibanaMigrator -> NP SavedObjectsService * SavedObjectsService never stop retrying ES connection error * Move waiting for migrations to complete till after legacy service start * Fix ESArchiver's KibanaMigrator * Fix reload logging config tests * Run migrations on savedobjects start * Fix env tests * Fix and make legacy tests more robust/isolated * Cleanup code * Fix invalid config test * Fix SavedObject Migrations logging test * SavedObjectsService tests * Lifecycle logging and improve getting kibanaConfig instance * Fix awaitMigration bug and test * Fix typing error * Review comments * Remove unecessary KibanaConfig class * Move legacy plugin config extension, specs, uiExports entirely into Core uiExports, specs, disabledSpecs, config now get injected into KbnServer * Fix config deprecation test * Use existing logger mock * Create SavedObjectsConfig for migration config * Define KibanaMigratorContract type * KibanaMigratorContract -> IKibanaMigrator + docs improvements * Fix esArchiver's KibanaMigrator * Fix plugin generator integration test * ConfigServiceContract -> IConfigService * Address review comments * Review nits * Document migrations.skip config * Review comments continued... * awaitMigrations -> runMigrations * Type improvements
Pinging @elastic/kibana-platform (Team:Platform) |
Thanks to #43433 being merged we no longer need to wait for the migrations to run as they are guaranteed to have run by the time plugin init has completed. This is just a cleanup making it easier to move towards the migration to the Kibana Platform.
Thanks to #43433 being merged we no longer need to wait for the migrations to run as they are guaranteed to have run by the time plugin init has completed. This is just a cleanup making it easier to move towards the migration to the Kibana Platform.
Note to reviewers: The code isn't 100% there yet and still has large blocks of commented out code, but I'd like some feedback on the approach before tidying up.Edit: updated after conversations
Summary
This PR moves the KibanaMigrator out of the legacy KbnServer
savedObjectsMixin
into a new Core SavedObjectsService. The SavedObjecsService creates aKibanaMigrator
and injects this migrator into the LegacyService/KbnServer.Background
This unblocks the larger effort of exposing the Saved Objects client on the server-side which has the following dependency
SavedObjectsClient
->SavedObjectsRepository
->KibanaMigrator
.Before this PR, KbnServer would load and initialize plugins before saved object migrations were completed. Migrations would run in the background while all Saved Object operations are buffered until the migrations are complete. This has sometimes led to subtle bugs where Elasticsearch write operations were performed against the
.kibana
index which would effectively break kibana or lead to data-loss. (Although plugins run in parallel with migrations, we would only listen to HTTP requests once migrations are complete.)In contrast, the SavedObjectsService is started before the LegacyService (which initializes legacy plugins) and Http service and the start phase will block until all migrations have completed. This means no plugins can run and no HTTP requests will be received until migrations are completed.
Handling ES connectivity errors
Until we have a solution for #43456 the SavedObjectsService will retry any connectivity errors to elasticsearch indefinitely. Although we no longer rely on this logic being embedded in the Elasticsearch plugin's healthcheck, the behaviour stays the same:
migrations.skip
configuration optionTo perform migrations, we need an active connection to Elasticsearch. However, for building (
--optimize
and testing (grunt run:testBrowser
) we run the Kibana server without an Elasticsearch cluster but still depend on the HTTP server to start up. This would be done by disabling the legacy Elasticsearch plugin which in turn would disable migrations so that startup isn't blocked on migrations.Since in the NP we can no longer rely on disabling the Elasticsearch plugin, I introduced the
migrations.skip
configuration option.Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.For maintainers