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] Wildcard - stage 1 proposal #904

Merged
merged 16 commits into from
Sep 15, 2020
Merged

Conversation

ebeahan
Copy link
Member

@ebeahan ebeahan commented Jul 31, 2020

Summary

Revisions to the stage 0 wildcard adoption for consideration to be accepted as a stage 1 proposal.

Criteria for consideration

  • Opened pull request revising the existing strawperson
  • Identified "sponsor" at Elastic who will participate in RFC process and take ownership of the change after the process completes
  • Types of fields or changes outlined
  • High-level description of examples of usage
  • High-level description of example sources of data
  • Identified potential concerns and implementation challenges/complexity
  • Subject matter experts identified and weighed in on the high level utility of these changes in the pull request
  • ECS team weighed in on appropriateness of these changes in the pull request

Markdown preview of this RFC

@ebeahan ebeahan added the RFC label Jul 31, 2020
@ebeahan ebeahan self-assigned this Jul 31, 2020
@ebeahan ebeahan changed the title [RFC] Wildcard - stage 1 [RFC] Wildcard - stage 1 proposal Jul 31, 2020
@ebeahan
Copy link
Member Author

ebeahan commented Aug 13, 2020

Seeking feedback from folks on the wildcard adoption RFC. I've noted a few areas needing discussion before advancing as stage one:

  • Any concerns with the outlined approach or any critical missing use cases that should be captured?
  • Any concerns or implementation challenges overlooked?
  • Any field sets not mentioned that should be represented? (Any specifics on particular fields is also welcomed.)

@webmat @jamiehynds @epixa @rw-access @randomuserid @leehinman @jonathan-buttner

@ebeahan ebeahan added the ready Issues we'd like to address in the future. label Aug 18, 2020
Copy link
Contributor

@webmat webmat left a comment

Choose a reason for hiding this comment

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

Fantastic work, this is looking great!

I have a lot of comments below.

On the criteria checklist, I will check the ECS team weighing in checkbox. There's a few adjustments needed still for stage 1, but we're almost there I think. The approving PR review will be the actual gate, here. 🙂

On the other two criteria, let's leave until beginning of next week for folks to chime in, perhaps? But I think this stage 1 PR is solid enough to be merged soon, and we can tackle the nitty gritty details in the stage 2 PR.

The stage 2 PR is (among others) when I expect us to start listing exhaustively each field we will consider moving to wildcard. This is the moment where other SMEs participating actively will be a blocker for acceptance at stage 2.

rfcs/text/0001-wildcard-data-type.md Show resolved Hide resolved
rfcs/text/0001-wildcard-data-type.md Outdated Show resolved Hide resolved
rfcs/text/0001-wildcard-data-type.md Outdated Show resolved Hide resolved
rfcs/text/0001-wildcard-data-type.md Outdated Show resolved Hide resolved
rfcs/text/0001-wildcard-data-type.md Outdated Show resolved Hide resolved
rfcs/text/0001-wildcard-data-type.md Outdated Show resolved Hide resolved
rfcs/text/0001-wildcard-data-type.md Outdated Show resolved Hide resolved
rfcs/text/0001-wildcard-data-type.md Outdated Show resolved Hide resolved
rfcs/text/0001-wildcard-data-type.md Show resolved Hide resolved
rfcs/text/0001-wildcard-data-type.md Show resolved Hide resolved
@ebeahan
Copy link
Member Author

ebeahan commented Aug 21, 2020

Thanks @webmat for all the great, detailed feedback! I've made all the suggested changes except for the review comment discussing hostname, email, and username. I'm leaning towards removing all three from that section. WDYT?

@webmat
Copy link
Contributor

webmat commented Aug 26, 2020

the review comment discussing hostname, email, and username. I'm leaning towards removing all three from that section.

Let's leave it in for now. In stage 2, when we start doing a comprehensive list of all fields we consider migrating, we can come to a decision on this, and remove that section if appropriate.

@ebeahan
Copy link
Member Author

ebeahan commented Sep 3, 2020

@cyrille-leclerc @leehinman following up from our discussion last week, would you be able to briefly review and weigh in on the utility of these changes and any concerns or complexity that isn't captured?

webmat
webmat previously approved these changes Sep 4, 2020
Copy link
Contributor

@webmat webmat left a comment

Choose a reason for hiding this comment

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

I think we have a good coverage of the potential concerns. Let's check that box :-)

For my part, I'm good with this stage 1 proposal as it is 🚢

We're only waiting for a quick thumbs up / thumbs down from observability and security

@leehinman and @cyrille-leclerc (or representatives), what we're looking for at stage 1 is simply whether or not we've missed a big concern from your point of view, and whether or not this is heading in the right direction. Stage 2 is when we will hammer out the precise list of fields to migrate, and that's therefore when we will need more thorough reviews. For now I think a cursory review is enough.

### Ingestion

Any component producing data (Beats, Logstash, third-party developed, etc.) will need to comply with the new mappings.
Any component producing data (Beats, Logstash, third-party developed, etc.) will need to adopt the mappings in their index templates. The discussion around the handling of OSS vs. Basic field types between OSS and Basic modules/plugins will be handled outside of this proposal.

Copy link
Contributor

Choose a reason for hiding this comment

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

Another important item outside the scope of this proposal is backwards compatibility. Producers will need to consider the case where the producer has adopted wildcard, but the Elasticsearch instance they are sending data to doesn't support wildcard (example ES 6.8).

@leehinman
Copy link
Contributor

+1 for moving to Stage 2

@roncohen
Copy link
Contributor

generally LGTM 👍

@ebeahan ebeahan merged commit a4655d4 into elastic:master Sep 15, 2020
@ebeahan ebeahan deleted the wildcard-rfc-stage-1 branch September 15, 2020 15:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready Issues we'd like to address in the future. RFC
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants