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

Migrate server-side ES domain to packages #136297

Merged

Conversation

pgayvallet
Copy link
Contributor

@pgayvallet pgayvallet commented Jul 13, 2022

Summary

Fix #136283

  • Create the following packages

    • @kbn/core-elasticsearch-server
    • @kbn/core-elasticsearch-client-server-internal
    • @kbn/core-elasticsearch-client-server-mocks
    • @kbn/core-elasticsearch-server-internal
    • @kbn/core-elasticsearch-server-mocks
  • Move the content of src/core/server/elasticsearch accordingly

  • Adapt internal and external usages / imports

@pgayvallet pgayvallet added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v8.4.0 labels Jul 14, 2022
@pgayvallet pgayvallet requested a review from a team as a code owner July 15, 2022 07:00
@elasticmachine
Copy link
Contributor

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

@pgayvallet pgayvallet requested review from pzl and joeypoon July 15, 2022 07:00
@pgayvallet pgayvallet added backport:skip This commit does not require backporting release_note:skip Skip the PR/issue when compiling release notes labels Jul 15, 2022
Copy link
Contributor

@cjcenizal cjcenizal left a comment

Choose a reason for hiding this comment

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

Changes to imports in Upgrade Assistant tests LGTM.

@botelastic botelastic bot added Team:Fleet Team label for Observability Data Collection Fleet team Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability labels Jul 15, 2022
@elasticmachine
Copy link
Contributor

Pinging @elastic/fleet (Team:Fleet)

@elasticmachine
Copy link
Contributor

Pinging @elastic/uptime (Team:uptime)

Copy link
Contributor

@ymao1 ymao1 left a comment

Choose a reason for hiding this comment

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

Response Ops changes LGTM

Copy link
Contributor

@juliaElastic juliaElastic left a comment

Choose a reason for hiding this comment

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

Fleet change LGTM

@@ -9,3 +9,5 @@
export type { PluginOpaqueId, PluginName, DiscoveredPlugin } from './plugins';
export { PluginType } from './plugins';
export { EUI_STYLES_GLOBAL } from './eui';
export { ServiceStatusLevels } from './service_status';
Copy link
Contributor

Choose a reason for hiding this comment

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

core-base-common seems to be morphing into a "catch-all" I-don't-know-where-to-put-this-thing package. It's fine for now as the package is still very small. During the cleanup phase or slightly prior to that, we should audit everything in core-base-* packages and see if we could organize the components into a domain-like structure.

Copy link
Contributor Author

@pgayvallet pgayvallet Jul 19, 2022

Choose a reason for hiding this comment

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

core-base-common seems to be morphing into a "catch-all" I-don't-know-where-to-put-this-thing package

Yup, I totally agree. The intent here is to avoid the 'lets create 99 another one-file packages before the end of the migration' effect. We move all the 'misc' stuff here, and we'll revisit once everything has been moved.

During the cleanup phase or slightly prior to that, we should audit everything in core-base-* packages and see if we could organize the components into a domain-like structure

Fully agree too.

Copy link
Contributor

@TinaHeiligers TinaHeiligers Jul 19, 2022

Choose a reason for hiding this comment

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

From a quick search through core, it's elasticsearch, status, and savedObjects that all use the types from status. Am I missing any other core domains in this list?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, AFAIK for now only the ES and SO services declare their statuses.

Copy link
Member

@ashokaditya ashokaditya left a comment

Choose a reason for hiding this comment

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

security_solution/server/endpoint changes LGTM.

Copy link
Contributor

@nkhristinin nkhristinin left a comment

Choose a reason for hiding this comment

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

Reviewed security-solution-platform files. LGTM!

Copy link
Contributor

@fkanout fkanout left a comment

Choose a reason for hiding this comment

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

Actionable Observability changes LGTM.

@pgayvallet pgayvallet removed request for pzl and joeypoon July 19, 2022 08:32
Copy link
Contributor

@marshallmain marshallmain left a comment

Choose a reason for hiding this comment

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

Detection alerts changes LGTM

} from './retry_unauthorized';
ICustomClusterClient,
} from '@kbn/core-elasticsearch-server';
import type { ElasticsearchClientConfig } from '@kbn/core-elasticsearch-server';
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: combine imports from @kbn/core-elasticsearch-server

} from '@elastic/transport';
import type { TransportOptions } from '@elastic/transport/lib/Transport';
import { Transport } from '@elastic/elasticsearch';
import {
Copy link
Contributor

Choose a reason for hiding this comment

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

Aside: are we going to standardize combining imports from the same place in this manner rather than declaring type imports separately?

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.

I left a bunch of comments and questions but these aren't strictly related to this PR.
The tradeoffs, compromises, and tasks left for future work are all more than reasonable, considering that migrating the elasticsearch core domain is one of our largest.
Great work!
LGTM.

import { ScopedClusterClient } from './scoped_cluster_client';

const createEsClient = () => ({} as unknown as ElasticsearchClient);
Copy link
Contributor

Choose a reason for hiding this comment

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

Aside: I feel we need to come up with a simple rule of thumb on how to approach internal implementations' unit tests using what will be public mocks. With our dependency structure in the Kibana-as-packages world, we forbid that.

A rule of thumb could be:

  • if manual stubbing is easy, replace the mock with a manual stub.
  • if a mock depends on other mocks, create duplicates of these for use internally.

Does that sound reasonable as an interim solution?

import { ICustomClusterClient } from './cluster_client';
import { PRODUCT_RESPONSE_HEADER } from '../supported_server_response_check';
import type { ElasticsearchClient, ICustomClusterClient } from '@kbn/core-elasticsearch-server';
import { PRODUCT_RESPONSE_HEADER } from '@kbn/core-elasticsearch-client-server-internal';
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the issue of mocks depending on implementations? I thought it was the reverse we can't have. In other words, we cannot have the implementations using mocks.

If its just a bundle size concern, in that we're forcing a dependency just for a header string, then yes, we can come back later and change it.

Comment on lines -19 to -20
// Mocking the module to disable caching for tests
jest.mock('../ui_settings/cache');
Copy link
Contributor

Choose a reason for hiding this comment

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

hehehe, see the reviewers on #133017

* Fake request object created manually by Kibana plugins.
* @public
*/
export interface FakeRequest {
Copy link
Contributor

Choose a reason for hiding this comment

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

I wondered where these went. Moving ScopeableRequest to its own file with the same name nicely separates out concerns.

@@ -20,8 +20,9 @@ import type { CoreContext, CoreService } from '@kbn/core-base-server-internal';
import type { LoggingConfigType } from '@kbn/core-logging-server-internal';
import type { Logger } from '@kbn/logging';
import type { HttpConfigType, InternalHttpServiceSetup } from '@kbn/core-http-server-internal';
import type { ElasticsearchServiceStart } from '@kbn/core-elasticsearch-server';
import type { ElasticsearchConfigType } from '@kbn/core-elasticsearch-server-internal';
Copy link
Contributor

Choose a reason for hiding this comment

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

Using exposed internal types within core is needed but there's nothing preventing external consumers from using the internal types either. It's maybe too early to say, but how should we approach the need for sometimes having to use internal core domain types outside of core?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's maybe too early to say, but how should we approach the need for sometimes having to use internal core domain types outside of core?

The initial idea was to simply forbid import from -internal package by consumers outside of Core via an ESlint rule. Note that now that we progressed quite a bit in the migration, we can say that this will cause problem given we saw that some 'internal' stuff is (at least currently) exported from these packages by our entrypoints and consumed externally.

One option could be to extract those parts to dedicated 'util' packages, or maybe have a way to flag things that are allowed to import from internal packages. I'm not sure yet to be honest. We definitely need to think about it once we complete the rest of the migration.

Comment on lines +118 to +121
export { ElasticsearchConfig, pollEsNodesVersion } from '@kbn/core-elasticsearch-server-internal';
export type {
NodesVersionCompatibility,
PollEsNodesVersionOptions,
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like we both had the same thoughts.

@@ -8,10 +8,11 @@

import { catchRetryableEsClientErrors } from './catch_retryable_es_client_errors';
import { errors as EsErrors } from '@elastic/elasticsearch';
jest.mock('./catch_retryable_es_client_errors');
Copy link
Contributor

Choose a reason for hiding this comment

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

Does the order here matter? I ask because the order between the mock import and the file mock is switched in some tests but not in others.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

jest.mock order does not matter, and the consensus was to have them after the import lines

jest.doMock, or importing test.mocks.ts files performing jest.doMock order matter, and should usually be done before the imports

jest.mock is hoisted above import when used at top level and hoisted to the the beginning of the block when used in a block (test function scope, etc), same for jest.unmock. jest.doMock and jest.dontMock serve the same purpose but aren't hoisted.

Comment on lines -8 to -9
import // eslint-disable-next-line @kbn/eslint/no-restricted-paths
'@kbn/core/server/elasticsearch/client/mocks';
Copy link
Contributor

Choose a reason for hiding this comment

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

me too 🤔

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] Fleet Cypress Tests / Add Integration - Real API should install integration without policy
  • [job] [logs] Security Solution Tests #2 / EQL rules Detection rules, EQL Creates and enables a new EQL rule

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
core 355 356 +1

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/core-elasticsearch-client-server-internal - 9 +9
@kbn/core-elasticsearch-client-server-mocks - 32 +32
@kbn/core-elasticsearch-server - 51 +51
@kbn/core-elasticsearch-server-internal - 29 +29
@kbn/core-elasticsearch-server-mocks - 15 +15
core 705 664 -41
total +95

Any counts in public APIs

Total count of every any typed public API. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats any for more detailed information.

id before after diff
@kbn/core-elasticsearch-client-server-mocks - 1 +1
@kbn/core-elasticsearch-server-mocks - 1 +1
total +2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
core 136.4KB 136.4KB +3.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
core 342.3KB 342.9KB +616.0B
Unknown metric groups

API count

id before after diff
@kbn/core-base-common 12 20 +8
@kbn/core-elasticsearch-client-server-internal - 11 +11
@kbn/core-elasticsearch-client-server-mocks - 36 +36
@kbn/core-elasticsearch-server - 99 +99
@kbn/core-elasticsearch-server-internal - 33 +33
@kbn/core-elasticsearch-server-mocks - 15 +15
core 2472 2470 -2
total +200

ESLint disabled line counts

id before after diff
actions 22 20 -2
cloudSecurityPosture 12 7 -5
fleet 53 51 -2
lists 38 13 -25
monitoring 31 25 -6
monitoringCollection 2 0 -2
ruleRegistry 6 2 -4
securitySolution 439 425 -14
stackAlerts 23 22 -1
synthetics 62 61 -1
upgradeAssistant 11 9 -2
total -64

References to deprecated APIs

id before after diff
@kbn/core-elasticsearch-server-internal - 2 +2

Total ESLint disabled count

id before after diff
actions 28 26 -2
cloudSecurityPosture 13 8 -5
fleet 61 59 -2
lists 43 18 -25
monitoring 38 32 -6
monitoringCollection 2 0 -2
ruleRegistry 8 4 -4
securitySolution 513 499 -14
stackAlerts 24 23 -1
synthetics 68 67 -1
upgradeAssistant 11 9 -2
total -64

Unreferenced deprecated APIs

id before after diff
@kbn/core-elasticsearch-server - 1 +1

History

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

@pgayvallet pgayvallet merged commit 3508350 into elastic:main Jul 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting 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 Team:Fleet Team label for Observability Data Collection Fleet team Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability v8.4.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Migrate types to packages: Server-side elasticsearch service