-
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
Migrate server-side ES domain to packages #136297
Migrate server-side ES domain to packages #136297
Conversation
…-ref HEAD~1..HEAD --fix'
…ide-es-to-packages
…ide-es-to-packages
…-ref HEAD~1..HEAD --fix'
Pinging @elastic/kibana-core (Team:Core) |
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.
Changes to imports in Upgrade Assistant tests LGTM.
Pinging @elastic/fleet (Team:Fleet) |
Pinging @elastic/uptime (Team:uptime) |
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.
Response Ops changes LGTM
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.
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'; |
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.
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.
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.
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.
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.
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?
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.
No, AFAIK for now only the ES and SO services declare their statuses.
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.
security_solution/server/endpoint
changes LGTM.
…ide-es-to-packages
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.
Reviewed security-solution-platform files. LGTM!
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.
Actionable Observability changes LGTM.
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.
Detection alerts changes LGTM
} from './retry_unauthorized'; | ||
ICustomClusterClient, | ||
} from '@kbn/core-elasticsearch-server'; | ||
import type { ElasticsearchClientConfig } from '@kbn/core-elasticsearch-server'; |
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.
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 { |
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.
Aside: are we going to standardize combining imports from the same place in this manner rather than declaring type
imports separately?
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.
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); |
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.
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'; |
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.
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.
// Mocking the module to disable caching for tests | ||
jest.mock('../ui_settings/cache'); |
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.
hehehe, see the reviewers on #133017
* Fake request object created manually by Kibana plugins. | ||
* @public | ||
*/ | ||
export interface FakeRequest { |
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.
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'; |
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.
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?
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.
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.
export { ElasticsearchConfig, pollEsNodesVersion } from '@kbn/core-elasticsearch-server-internal'; | ||
export type { | ||
NodesVersionCompatibility, | ||
PollEsNodesVersionOptions, |
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.
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'); |
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.
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.
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.
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.
import // eslint-disable-next-line @kbn/eslint/no-restricted-paths | ||
'@kbn/core/server/elasticsearch/client/mocks'; |
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.
me too 🤔
…ide-es-to-packages
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Public APIs missing comments
Any counts in public APIs
Async chunks
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
Unreferenced deprecated APIs
History
To update your PR or re-run it, just comment with: |
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
accordinglyAdapt internal and external usages / imports