mirror of
https://github.com/elastic/kibana.git
synced 2025-04-23 09:19:04 -04:00
78647b01ee
## Summary Allows hiding project specific features using tier specific config files. We need this to be able to gate certain features on a new serverless tier (`searchAiLake`) that is a subset of features from `essentials`/`complete`. The following illustration outlines the approach with tier specific serverless config files.  ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] [See some risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) - [ ] ... |
||
|---|---|---|
| .. | ||
| kibana.yml | ||
| node.options | ||
| README.md | ||
| serverless.es.yml | ||
| serverless.oblt.yml | ||
| serverless.security.complete.yml | ||
| serverless.security.essentials.yml | ||
| serverless.security.search_ai_lake.yml | ||
| serverless.security.yml | ||
| serverless.yml | ||
as work on serverless picks up we will add config values to these files that
define how Kibana will run in "serverless" modes. To start Kibana locally with
this configuration, pass --serverless={mode} or run yarn serverless-{mode}
valid modes are currently: es, oblt, and security
configuration is applied in the following order, later values override
- serverless.yml (serverless configs go first)
- serverless.{mode}.yml (serverless configs go first)
- base config, in this preference order:
- my-config.yml(s) (set by --config)
- env-config.yml (described by
env.KBN_CONFIG_PATHS) - kibana.yml (default @
env.KBN_PATH_CONF/kibana.yml)
- kibana.dev.yml
- serverless.dev.yml
- serverless.{mode}.dev.yml