-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Cleanup enabled: false
saved objects mappings
#149102
Changes from 2 commits
19e63eb
46d8c13
e2b1316
fa6339a
1aa1e94
5767058
0f1fcd5
d43a0a5
798de73
c8335bf
647c639
d165f61
3dd40d7
8d158be
a977e92
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -61,23 +61,6 @@ export function setupSavedObjects( | |
); | ||
}, | ||
}); | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, this resolves #139347 for maps. Question, will this impact upgrades? If a cluster has set this value in previous versions, will the cluster be able to upgrade? We have seen some SDHs regarding upgrade failures for maps-telemetry and clusters that have previously set this value. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. By adding it to the |
||
/* | ||
* The maps-telemetry saved object type isn't used, but in order to remove these fields from | ||
* the mappings we register this type with `type: 'object', enabled: true` to remove all | ||
* previous fields from the mappings until https://github.com/elastic/kibana/issues/67086 is | ||
* solved. | ||
*/ | ||
core.savedObjects.registerType({ | ||
name: 'maps-telemetry', | ||
hidden: false, | ||
namespaceType: 'agnostic', | ||
mappings: { | ||
// @ts-ignore Core types don't support this since it's only really valid when removing a previously registered type | ||
type: 'object', | ||
enabled: 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.
@elastic/fleet
Nested mappings is rather "expensive" because it creates a document for each object in the array. It also enforces other limits like 50 nested fields per index and only 10000 objects per array.
https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html#_limits_on_nested_mappings_and_objects
Given that we previously had
enabled: false
we were never querying these fields. By extension we wouldn't need the advantages of thenested
type either. Which makes me lean towards removing it.BUT it's not possible to change the type later on (it's an incompatible mapping change) so if we have any reason to believe we'd need to run nested queries on the inputs in the future it would be better keeping it.
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.
@rudolf - Thanks for the ping. I can't imagine we'd need to run nested queries on this
inputs
field, so I'd be in favor of just biting the bullet on this mapping change to justdynamic: false
+properties: {}
like the others now.