Skip to content

docs: document applies_to authoring for settings YAML - #4014

Open
florent-leborgne wants to merge 6 commits into
elastic:mainfrom
florent-leborgne:flb/settings-yaml-applies-to
Open

docs: document applies_to authoring for settings YAML#4014
florent-leborgne wants to merge 6 commits into
elastic:mainfrom
florent-leborgne:flb/settings-yaml-applies-to

Conversation

@florent-leborgne

@florent-leborgne florent-leborgne commented Sep 2, 2026

Copy link
Copy Markdown
Member

Why

Kibana settings YAML files treat automated_settings.md as the schema source of truth. That page previously said {settings} YAML follows the same applies_to rules as page Markdown. Authors then omitted deployment keys or copied stack: preview onto ech.

What

Documents the settings-YAML authoring contract. stack carries lifecycle and version. ech, ece, eck, self, and serverless are support flags (ga or unavailable).

For Advanced Settings that exist on only some serverless projects, nest elasticsearch, observability, or security under serverless. Write a scalar serverless: ga or serverless: unavailable when every project matches. Do not mix a scalar serverless: with project keys.

The syntax example YAML now uses a complete map, including stack: preview plus ech: ga.

Related: elastic/kibana#288454

Settings YAML uses the same keys as body Markdown, but deployment
keys are support flags so the Supported on line stays readable.

Co-authored-by: Cursor <cursoragent@cursor.com>

@natasha-moore-elastic natasha-moore-elastic left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Left some questions :)

Comment thread docs/syntax/automated_settings.md Outdated
Comment thread docs/syntax/automated_settings.md Outdated
Comment thread docs/syntax/automated_settings.md Outdated
Comment thread docs/syntax/automated_settings.md Outdated
|---|---|---|
| `stack` | Lifecycle and version of the setting | `ga`, `preview 9.2`, or a history such as `preview 9.0-9.2, ga 9.3+`. No version means all versions. |
| `ech`, `ece`, `eck`, `self` | Supported on that deployment, or not | Always list all four. `ga` if supported. `unavailable` if not. Never a version. Never `preview`, `experimental`, `deprecated`, or `removed`. |
| `serverless` | Supported on serverless, or not | Always list it. `ga` if supported. `unavailable` if not. Never a version. |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What about the serverless-project keys (security, observability, etc.)? Should they not be used in YAML settings, and we just use the serverless key instead? If so, can we call this out somewhere?
Or if they can be used, should we have a line for them here?

florent-leborgne and others added 5 commits September 2, 2026 17:17
Co-authored-by: natasha-moore-elastic <137783811+natasha-moore-elastic@users.noreply.github.com>
A scalar serverless flag over-claims when a setting exists on only
one serverless project. Nest elasticsearch, observability, and
security when they differ.

Co-Authored-By: Cursor Grok 4.6 <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Advanced Settings may exist on only some serverless projects.
Nest elasticsearch, observability, or security when that is true.

Co-Authored-By: Cursor Grok 4.6 <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants