Skip to content
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

Merged
merged 47 commits into from
Oct 1, 2019

Conversation

rudolf
Copy link
Contributor

@rudolf rudolf commented Aug 16, 2019

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 a KibanaMigrator 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:

  1. When kibana is started without any Elasticsearch connection:
  • Kibana starts the "notReadyServer", but the HTTP server doesn't yet serve any routes.
  1. When Elasticsearch becomes unavailable after Kibana had successfully started
  • We display the "Cannot connect to the Elasticsearch cluster. See the Kibana logs for details and try reloading the page." page on the Kibana UI.

migrations.skip configuration option

To 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 strikethroughs to remove checklist items you don't feel are applicable to this PR.

For maintainers

@rudolf rudolf force-pushed the server-saved-objects-service branch 2 times, most recently from cd9ea4d to f7cea53 Compare August 20, 2019 14:04
@rudolf rudolf force-pushed the server-saved-objects-service branch from b70eff5 to ea6486a Compare August 22, 2019 12:10
@rudolf rudolf marked this pull request as ready for review August 22, 2019 13:30
@rudolf rudolf requested review from a team as code owners August 22, 2019 13:30
@rudolf rudolf added the release_note:skip Skip the PR/issue when compiling release notes label Aug 22, 2019
@rudolf rudolf changed the title Server saved objects service Move KibanaMigrator into Server SavedObjectsService Aug 22, 2019
@joshdover
Copy link
Contributor

The behavior here sounds good, though I haven't tested it myself yet.

My main questions are related to the --skip-migrations flag. When possible, I think we should try to reduce the number of configs & cli flags to reduce the combinational complexity of configurations. I'm curious if there's a single semantic that conveys the different cases that need to use this flag and other existing options.

Do you know why grunt run:testBrowser needs the HTTP server? Which endpoints does it use or is it just serving static files?

@rudolf
Copy link
Contributor Author

rudolf commented Aug 22, 2019

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.

Copy link
Contributor

@walterra walterra left a comment

Choose a reason for hiding this comment

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

ML changes LGTM

@rudolf
Copy link
Contributor Author

rudolf commented Aug 23, 2019

We need to support two behaviours:

  1. Run Optimizer and exit, ran as part of the build process. This is already supported with the --optimize flag. Since the optimizer also optimizes plugin bundles it requires scanning for plugins.
  2. Compile tests bundle and serve tests bundle to browser. The test bundle is created in the tests plugin https://github.com/elastic/kibana/blob/master/src/legacy/core_plugins/tests_bundle/index.js#L102 and then we use '--optimize.bundleFilter=tests' so that this is the only bundle being served https://github.com/elastic/kibana/blob/master/tasks/config/run.js#L61

Instead of introducing a new --skip-migrations flag which describes what happens, but not why, we could create a --serve-tests-bundle (or something similar) flag which better expresses the intention that we're starting up a reduced functionality Kibana for the single purpose of building and serving test files. I'm not sure how much of a difference this would make, but we could later theoretically use this flag to disable more parts of Core to speed up this testing server.

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?

@joshdover
Copy link
Contributor

Is this ready for review? I noticed some WIP code in the service class: https://github.com/elastic/kibana/pull/43433/files#diff-e77c8c0ea344aeee10b656f96c2a3f4aR123

@rudolf rudolf requested a review from a team September 27, 2019 19:25
@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

const createConfigServiceMock = ({
atPath = {},
getConfig$ = {},
}: { atPath?: unknown; getConfig$?: Record<string, any> } = {}) => {
Copy link
Contributor

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 });

@epixa epixa mentioned this pull request Sep 30, 2019
20 tasks
@joshdover joshdover mentioned this pull request Sep 30, 2019
7 tasks
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Contributor

@gmmorris gmmorris left a 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.

@rudolf rudolf merged commit 85c8232 into elastic:master Oct 1, 2019
@rudolf rudolf deleted the server-saved-objects-service branch October 1, 2019 07:11
rudolf added a commit to rudolf/kibana that referenced this pull request Oct 1, 2019
* 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
rudolf added a commit that referenced this pull request Oct 1, 2019
* 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
@epixa epixa added the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Nov 21, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform (Team:Platform)

gmmorris added a commit that referenced this pull request Nov 25, 2019
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.
gmmorris added a commit that referenced this pull request Nov 26, 2019
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.
timductive pushed a commit to timductive/kibana that referenced this pull request Dec 16, 2019
Thanks to elastic#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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.5.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants