-
Notifications
You must be signed in to change notification settings - Fork 73
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
Add missing properties to fields.yml spec #314
Conversation
- geo_point | ||
- object | ||
- group |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fleet EPM has a group-nested
type. Does that need added to the list? Why would we have both group-nested
and nested
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see this type used in integrations nor in beats, I would say to don't add it here, we can add it in a follow up if needed.
@joshdover do you know why this type is in Fleet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was added 2 years ago in this pr, but doesn't say a lot of context about why: elastic/kibana#64829
this logic here sets group-nested
type: https://github.com/jonathan-buttner/kibana/blob/22b4a693eaaba401b5385d6341a0e9fcf9ff518f/x-pack/plugins/ingest_manager/server/services/epm/fields/field.ts#L147-L151
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't try to follow the logic, but my take is that is seems like an internal-only value. So none of the integrations should use group-nested
and it does not need to be in the spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @andrewkroh! Awesome revamp of the fields spec.
- geo_point | ||
- object | ||
- group |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see this type used in integrations nor in beats, I would say to don't add it here, we can add it in a follow up if needed.
@joshdover do you know why this type is in Fleet?
Only honored for 'type: text/keyword/wildcard'. | ||
$ref: "#" # JSON-schema syntax for pointing to the root of the schema | ||
|
||
# TODO: Fleet only honors this for 'type: wildcard'. That seems wrong. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping @joshdover
# TODO: We should disable additionalProperties. There are properties used in | ||
# elastic/integrations that have no purpose or are typos. | ||
additionalProperties: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, specially after adding these missing properties. @mtojek wdyt?
# TODO: We should disable additionalProperties. There are properties used in | |
# elastic/integrations that have no purpose or are typos. | |
additionalProperties: true | |
# TODO: We should disable additionalProperties. There are properties used in | |
# elastic/integrations that have no purpose or are typos. | |
additionalProperties: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on my side too.
I think that we left it open to allow for extra properties like examples, patterns, etc. It seems that we aren't using the actively, so let's close this option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I set additionalProperties: false
and adjusted some of the test packages to remove level, group, and title.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are many fields using level, group and/or title in the integrations repo, wdyt about adding these fields here by now? We could add them directly as deprecated, and eventually phase them out.
I have created this PR to check what would fail in the integrations repo after this change: elastic/integrations#3024
We'll need to investigate why these are in Fleet. Then either add them here or remove them from Fleet.
@juliaElastic Do you have time to review this? I believe you're more up to date on our mapping field logic than I am. |
I can have a look later today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I have updated elastic/integrations#3024, and there are still some missing fields ( @andrewkroh @mtojek wdyt about setting |
👍 That's what I'm thinking to do. Even if we remove level, group, title, example there will still be some keys related to dynamic fields that we need to account for. So after we specify the dynamic field behavior we can make this strict. |
test/packages/missing_required_fields/data_stream/foo/fields/some_fields.yml
Outdated
Show resolved
Hide resolved
This reverts commit b9b5fc1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I have updated elastic/integrations#3024 as a last check in case there is something unexpected.
@@ -35,3 +35,15 @@ | |||
- name: error.message | |||
description: Error message. | |||
type: match_only_text | |||
- name: metric.*_bytes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit. Is this an intentional test case? We don't use to have wildcards mixed with suffixes, not sure if everything works as expected with this.
- name: metric.*_bytes | |
- name: metric.*.bytes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was intentional to test the pattern
specified for name
. It really is an area of unspecified behavior at the moment. I was operating under the assumption that wildcards will be used to implement behavior similar to path_match
. But for now this is a test case just to check that the pattern matches fields like this:
We should refine this area of the spec for dynamic fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could remove the pattern
for now. Then when we get to dynamic fields add it back to match the definition there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh ok, lets leave it. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pending failures in elastic/integrations#3024 don't seem to be related to this, but to #309.
@@ -35,3 +35,15 @@ | |||
- name: error.message | |||
description: Error message. | |||
type: match_only_text | |||
- name: metric.*_bytes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh ok, lets leave it. Thanks.
I've been looking over the issues in the integrations repo. After fixing many unused fields and typos (see https://github.com/elastic/integrations/pull/3239/commits) this is what's left:
|
99e3c40
to
5953a0e
Compare
5953a0e
to
86254fe
Compare
After allowing a dash there are three issues with names, and they all seems like problems with the integration (ignoring issues from the
So I think this is good now. |
@kaiyan-sheng do you expect any problem if we fix these fields to don't contain unexpected characters? |
@jsoriano Hmmm good catch, I don't think we are actually storing dimensions like this. For example, this dimension is stored as |
@kaiyan-sheng Thanks for addressing RDS in elastic/integrations#3253. Is the SNS dimension a bug or are we expecting to have JSON key names containing commas? |
@andrewkroh Good catch! SNS dimension is also a bug and I just added the fix into the same PR. Thank you! |
I think this is ready now. I will start creating follow-up issues for the things listed in the PR description. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 thanks Andrew! @mtojek @juliaElastic any objection to merge this?
Oh, one thing would be missing, @andrewkroh could you please add a changelog entry? |
Ah, changelog is already here 🤦 Merging. |
What does this PR do?
I looked over the code in Fleet EPM to see what properties are used when generating templates and then updated the specification to match.
The current version is a draft because it contains commentary as "TODO"s.Why is it important?
A detailed and accurate specification is required to ensure the developers of integration packages and the implementors of the specification agree on the behavior.
Checklist
test/packages
that prove my change is effective.versions/N/changelog.yml
.Related issues
Author Notes
Based on feedback in this PR we need to follow up on these tasks.
null_value
should be supported by types other thanwildcard
.dynamic: runtime
.path_match
,path_unmatch
,match
,unmatch
, etc). This blocks development of [Fleet] dynamic_template mappings for wildcard field names are not installed kibana#129344. We'll want to address this before incorporating this intoelastic-package
so that there is a migration path for fields that "think" they are creating dynamic mappings today and are using unsupported properties.multi_field
onmatch_only_text
field types.norms
ontext
fields.format
does in Beats (e.g. applying a formatter to the data view).