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

[RFC] wip: data_stream - stage 2 #1145

Merged
merged 8 commits into from
Jan 4, 2021

Conversation

roncohen
Copy link
Contributor

@roncohen roncohen commented Nov 23, 2020

Moving this to stage 2

Preview the RFC

@webmat webmat changed the title wip: moving to stage 2 [RFC] wip: data_stream - stage 2 Nov 23, 2020
@webmat webmat added the RFC label Nov 23, 2020
@webmat
Copy link
Contributor

webmat commented Nov 23, 2020

Thanks for opening this @roncohen. Another quick initial change we can do here, is add this PR to the list of "RFC Pull Requests" at the end of the document.

@webmat webmat added the 1.8.0 label Nov 23, 2020
@ruflin ruflin self-requested a review November 30, 2020 13:44
@@ -31,6 +31,20 @@ data_stream.namespace | constant_keyword | A user defined namespace. Namespaces

In the new indexing strategy, the value of the data stream fields combine to the name of the actual data stream in the following manner `{data_stream.type}-{data_stream.dataset}-{data_stream.namespace}`. This means the fields can only contain characters that are valid as part of names of data streams.

The following is the field definitions as a `fields.yml`:

```yml
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's instead add these as a separate YML file at rfcs/text/0009/data_stream.yml.

It will require a definition for the field set as well.

The definitions for the fields should instead start from what we had in the table above in the RFC. It's fine to be a bit more terse than in the table though, for example we should only cover the currently expected values for namespace.type, and not mention "we expect values X and Y". The field definitions should also cover the character limitations.

Here's a starting point for the full YML file:

- name: data_stream
  title: Data Stream
  short: TODO
  description: TODO
  fields:

    - name: type
      level: extended
      type: keyword
      example: logs
      description: >
        A description

        with multiple paragraphs

        requires a 'short' description as well.
      short: A short version of the description.
    - name: dataset
# ...

@webmat
Copy link
Contributor

webmat commented Dec 2, 2020

@exekias Do you know who will take this one over for Ron?

@ruflin ruflin self-assigned this Dec 2, 2020
@ruflin
Copy link
Member

ruflin commented Dec 2, 2020

@webmat 🤚

@ruflin
Copy link
Member

ruflin commented Dec 22, 2020

@webmat @ebeahan I updated the fields.yml. Anything else needed here?

@ebeahan
Copy link
Member

ebeahan commented Dec 22, 2020

Thanks, @ruflin, for taking over authorship and moving this forward!

Here's what I see as outstanding:

  • An example source document or two in the Source document section. This proposal's additions are straight-forward, but it's a useful aid to demonstrate how the proposed fields are intended to be used.
  • Identify the new RFC sponsor and capture in the People section.

@ruflin
Copy link
Member

ruflin commented Dec 23, 2020

@ebeahan Updated, let me know if this works.

ebeahan
ebeahan previously approved these changes Jan 4, 2021
Copy link
Member

@ebeahan ebeahan left a comment

Choose a reason for hiding this comment

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

LGTM 👍

I'll adjust the advancement date prior to merging.

@ebeahan ebeahan merged commit 259823b into elastic:master Jan 4, 2021
@ruflin
Copy link
Member

ruflin commented Jan 5, 2021

@ebeahan Thanks for getting this in. By now there is also a blog post around this that we can reference / link in the future: https://www.elastic.co/blog/an-introduction-to-the-elastic-data-stream-naming-scheme Any next steps needs from my end?

@ebeahan
Copy link
Member

ebeahan commented Jan 5, 2021

@ruflin Thanks for sharing the blog post! I think it'd make a great addition to the proposal References section in the next stage.

Let's go ahead and open the next stage's PR, even if the only initial change is updating the stage from 2 to 3. We can use that PR to capture any concerns or feedback that arise.

@ruflin
Copy link
Member

ruflin commented Jan 6, 2021

Done: #1212

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants