Skip to content
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

Stage 3 Orchestrator RFC #1343

Merged
merged 4 commits into from
May 14, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 5 additions & 23 deletions rfcs/text/0012-orchestrator-field-set.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# 0012: Orchestrator field set creation

- Stage: **2 (candidate)** <!-- Update to reflect target stage. See https://elastic.github.io/ecs/stages.html -->
- Date: **2021-03-26** <!-- The ECS team sets this date at merge time. This is the date of the latest stage advancement. -->
- Stage: **3 (finished)** <!-- Update to reflect target stage. See https://elastic.github.io/ecs/stages.html -->
- Date: **2021-05-14** <!-- The ECS team sets this date at merge time. This is the date of the latest stage advancement. -->

There is currently no ECS field set for container orchestration engines. There is an example of an ECS
[use-case][0] for Kubernetes, but it largely relies on other ECS field sets, and doesn't cover all of the
Expand Down Expand Up @@ -93,10 +93,6 @@ The proposed change adds nine fields, as described below:
API version being used to carry out the action
```

<!--
Stage 3: Add or update all remaining field definitions. The list should now be exhaustive. The goal here is to validate the technical details of all remaining fields and to provide a basis for releasing these field definitions as beta in the schema. Use GitHub code blocks with yml syntax formatting.
-->

## Usage

The `orchestrator` field set will be used to capture typical concepts employed
Expand Down Expand Up @@ -198,10 +194,6 @@ Examples of source data include:
}
```

<!--
Stage 3: Add more real world example source documents so we have at least 2 total, but ideally 3. Format as described in stage 2.
-->

## Scope of impact

As this RFC involves the creation of an entirely new fieldset, no breaking
Expand Down Expand Up @@ -239,19 +231,8 @@ cover all the logical primitives of popular orchestrators. Input from contributo
who have experience with the various alternative orchestration providers would be
particularly valuable.

<!--
Stage 3: Document resolutions for all existing concerns. Any new concerns should be documented along with their resolution. The goal here is to eliminate the risk of churn and instability by resolving outstanding concerns.
-->

<!--
Stage 4: Document any new concerns and their resolution. The goal here is to eliminate risk of churn and instability by ensuring all concerns have been addressed.
-->

## Real-world implementations

<!--
Stage 4: Identify at least one real-world, production-ready implementation that uses these updated field definitions. An example of this might be a GA feature in an Elastic application in Kibana.
-->
*Resolution*: Input from various orchestrators has been considered to ensure this field
set remains as generic as possible.

## People

Expand All @@ -275,6 +256,7 @@ The following are the people that consulted on the contents of this RFC.
* Stage 0: https://github.com/elastic/ecs/pull/1209
* Stage 1: https://github.com/elastic/ecs/pull/1230
* Stage 2: https://github.com/elastic/ecs/pull/1299
* Stage 3: https://github.com/elastic/ecs/pull/1343

[0]: https://github.com/elastic/ecs/blob/master/use-cases/kubernetes.yml
[1]: https://kubernetes.io/docs/tasks/debug-application-cluster/audit/
Expand Down