From f89c715b229dd8ce78a06264eddc0bb299ade2e2 Mon Sep 17 00:00:00 2001 From: Aleh Zasypkin Date: Wed, 18 Jul 2018 13:39:36 +0200 Subject: [PATCH 1/2] Document the way new platform is integrated into legacy one. --- src/core/README.md | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/src/core/README.md b/src/core/README.md index e1b7e90014788..27dc5d18724cf 100644 --- a/src/core/README.md +++ b/src/core/README.md @@ -1,18 +1,30 @@ -# New Platform (Core) +# Core -All Kibana requests will hit the new platform first and it will decide whether request can be -solely handled by the new platform or request should be forwarded to the legacy platform. In this mode new platform does -not read config file directly, but rather transforms config provided by the legacy platform. In addition to that all log -records are forwarded to the legacy platform so that it can layout and output them properly. +Core is a set of systems (frontend, backend etc.) that Kibana and its plugins are built on top of. -## Starting plugins in the new platform +## Integration with the "legacy" Kibana -Plugins in `../core_plugins` will be started automatically. In addition, dirs to -scan for plugins can be specified in the Kibana config by setting the -`__newPlatform.plugins.scanDirs` value, e.g. +Most of the existing core functionality is still spread over "legacy" Kibana and it will take some time to upgrade it. +Kibana is still started using existing "legacy" CLI and bootstraps `core` only when needed. At the moment `core` manages +HTTP connections, handles TLS configuration and base path proxy. All requests to Kibana server will hit HTTP server +exposed by the `core` first and it will decide whether request can be solely handled by the new platform or request should +be proxied to the "legacy" Kibana. This setup allows `core` to gradually introduce any "pre-route" processing +logic, expose new routes or replace old ones handled by the "legacy" Kibana currently. + +Once config has been loaded and validated by the "legacy" Kibana it's passed to the `core` where some of its parts will +be additionally validated so that we can make config validation stricter with the new config validation system. Even though +new system provided by the `core` is also based on Joi internally it is complemented with custom rules tailored to our +needs (e.g. `byteSize`, `duration` etc.). That means that config values that are accepted by the "legacy" Kibana may be +rejected by the `core`. + +One can also define new configuration keys under `__newPlatform` if these keys are supposed to be used by the `core` only +and should not be validated by the "legacy" Kibana, e.g. ```yaml __newPlatform: plugins: scanDirs: ['./example_plugins'] ``` + +Even though `core` has its own logging system it doesn't output log records directly (e.g. to file or terminal), but instead +forward them to the "legacy" Kibana so that they look the same as the rest of the log records throughout Kibana. From b90fbcc8a0c37954b57909328c68c81fbf6a0611 Mon Sep 17 00:00:00 2001 From: Aleh Zasypkin Date: Thu, 19 Jul 2018 00:43:56 +0200 Subject: [PATCH 2/2] Improved text per review comment. --- src/core/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/core/README.md b/src/core/README.md index 27dc5d18724cf..c3b056f981726 100644 --- a/src/core/README.md +++ b/src/core/README.md @@ -13,9 +13,9 @@ logic, expose new routes or replace old ones handled by the "legacy" Kibana curr Once config has been loaded and validated by the "legacy" Kibana it's passed to the `core` where some of its parts will be additionally validated so that we can make config validation stricter with the new config validation system. Even though -new system provided by the `core` is also based on Joi internally it is complemented with custom rules tailored to our -needs (e.g. `byteSize`, `duration` etc.). That means that config values that are accepted by the "legacy" Kibana may be -rejected by the `core`. +the new validation system provided by the `core` is also based on Joi internally it is complemented with custom rules +tailored to our needs (e.g. `byteSize`, `duration` etc.). That means that config values that are accepted by the "legacy" +Kibana may be rejected by the `core`. One can also define new configuration keys under `__newPlatform` if these keys are supposed to be used by the `core` only and should not be validated by the "legacy" Kibana, e.g.