-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Conversation
84787b5
to
46d8c13
Compare
}, | ||
}, | ||
}, | ||
type: 'nested', // TODO Review: If we're not searching `nested` isn't necessary but it's not possible to change the type later |
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 the nested
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 just dynamic: false
+ properties: {}
like the others now.
enabled: false
saved objects mappings
Pinging @elastic/fleet (Team: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.
DataDiscovery changes LGTM
@@ -61,23 +61,6 @@ export function setupSavedObjects( | |||
); | |||
}, | |||
}); | |||
|
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, 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 comment
The reason will be displayed to describe this comment to others. Learn more.
By adding it to the REMOVED_TYPES
list in packages/core/saved-objects/core-saved-objects-migration-server-internal/src/core/unused_types.ts
any remaining maps-telemetry documents will be deleted upon the next upgrade. So it won't impact upgrades.
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.
ResponseOps changes LTGM. Code review only.
Pinging @elastic/kibana-core (Team:Core) |
Osquery tests should be passing now if you update the branch. Let's see then, 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.
Defend Workflows changes LGTM ✅
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.
Code review. The typings give me confidence that a string isn't being inserted into any of the changed properties in saved queries or saved search sessions.
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.
The params
on our legacy actions SO was always an object and these objects are now deprecated, so LGTM.
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Saved Objects .kibana field count
History
To update your PR or re-run it, just comment with: cc @rudolf |
…appings (#154473) **Related to:** elastic/security-team#6268 (internal) ## Summary For each of our Saved Object types, we must: 1. Remove any SO field mappings with `index: false` (or `enabled: false`, although a first pass was done in #149102) from our SO `mappings` declarations 2. Audit and remove any _unused_ SO fields to minimize our footprint This PR addresses these two requirements for this `security-rule` saved object type (prebuilt rule asset). ## Details Specifically, the PR removes the `name` field from the mappings because: - We don't filter, sort, search, or aggregate by it. - We might need to do it in the future for our prebuilt rule upgrade/installation workflows, but for now we're going to implement filtering, sorting, and pagination on the client side, thus there's no need for this mapping server-side. <img width="1295" alt="Screenshot 2023-04-05 at 15 19 10" src="https://user-images.githubusercontent.com/7359339/230094740-706a9a78-fec3-469e-a4ad-e8b7d7309c78.png"> Also, we may need to add more fields to this mapping in the future to implement further improvements for the prebuilt rule installation, upgrade, or deprecation workflows. ### Checklist - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] The unit test for SO mapping hashes has been updated. - [ ] More tests will be added as part of #148176 and #148192
Summary
Clean up saved object mappings to reduce the field count and make mappings more future-proof.
This PR attempts to remove all
enabled: false
mappings. It's not possible to toggle theenabled
property so it becomes impossible to ever query over a disabled field.type: 'object', enabled: 'false'
also provides worse validation since it's possible to index a string into such an object. So usingdynamic: false, properties: {}
provides better validation and is more future-proof allowing us to query over these fields should the need arise.Since these fields can't be queried over it should be safe to remove these mappings but please review and/or test to ensure there's no regressions. If your plugin every relied on the lack of validation for being able to ingest a
string
field into antype: 'object', enabled: 'false'
field this PR would now cause failures.Related: https://github.com/elastic/dev/issues/2189
Checklist
Delete any items that are not applicable to this PR.
Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.
When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:
For maintainers