docs: document applies_to authoring for settings YAML - #4014
Open
florent-leborgne wants to merge 6 commits into
Open
docs: document applies_to authoring for settings YAML#4014florent-leborgne wants to merge 6 commits into
florent-leborgne wants to merge 6 commits into
Conversation
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>
3 tasks
natasha-moore-elastic
left a comment
Contributor
There was a problem hiding this comment.
Left some questions :)
| |---|---|---| | ||
| | `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. | |
Contributor
There was a problem hiding this comment.
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?
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Kibana settings YAML files treat
automated_settings.mdas the schema source of truth. That page previously said{settings}YAML follows the sameapplies_torules as page Markdown. Authors then omitted deployment keys or copiedstack: previewontoech.What
Documents the settings-YAML authoring contract.
stackcarries lifecycle and version.ech,ece,eck,self, andserverlessare support flags (gaorunavailable).For Advanced Settings that exist on only some serverless projects, nest
elasticsearch,observability, orsecurityunderserverless. Write a scalarserverless: gaorserverless: unavailablewhen every project matches. Do not mix a scalarserverless:with project keys.The syntax example YAML now uses a complete map, including
stack: previewplusech: ga.Related: elastic/kibana#288454