-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Remove obsolete typed legacy index templates #80937
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -716,6 +716,11 @@ public void onIndexModule(IndexModule module) { | |||
public UnaryOperator<Map<String, IndexTemplateMetadata>> getIndexTemplateMetadataUpgrader() { | ||||
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. @droberts195 would it be possible to use this existing 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. We did use that up until #51765, where we switched to Line 57 in 51cee9e
Ironically So maybe if 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. Oh, sorry, I just looked at the code and saw you used it to remove old indices. Yes, I guess we could do it that way now too. 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. Actually, based on a recent test failure I think there's a complication and the ML approach is better for 7.16. With the approach of this PR, in a rolling upgrade in 7.16 the template will get removed when the first node gets upgraded to 7.16. But there could be some nodes in the cluster that only understand legacy templates. I suspect it's the reason behind https://gradle-enterprise.elastic.co/s/lz76r6wwt3eic for example, which is rolling from 7.5.2 to 7.16.0. I used your approach for transforms in #80948 because it's cleaner for 8.0+ where we can be sure that the version being upgraded from will understand the replacement composable templates. Transforms didn't exist in 6.x so there's no chance its templates include types and it's safe to wait until 8.0 to delete its legacy templates. But it seems that for the features that existed in 6.x, 7.16 needs the ability to only remove the legacy templates if the oldest node in the cluster understands the replacement (composable templates or system indices depending on the index). 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.
Would this be a different problem though? More of a problem with how we install templates more so than how we delete templates? In a rolling upgrade the master eligible nodes should be rolled last (as per our rolling upgrade documentation). So the I'm probably missing something, but I don't understand what the "manual" way of removing templates offers vs the infrastructure in 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.
I think that's only a recommendation, not compulsory. A problem will only arise if something is done in the mixed version cluster that causes an index to need to be created using the old template. For example, if after upgrading half the nodes from 7.5.2 to 7.16.0 a user creates an ML job that causes a new ML results index to be created and that gets actioned by a 7.5.2 node that needs the legacy template. Maybe you are correct that it's impossible for a legacy template to be needed after the upgraded master node has deleted it, but the effect of ML indices getting created without mappings causes complicated support issues so for ML I would rather stick with code that doesn't remove the legacy templates until the entire cluster is upgraded. 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.
IIRC the template upgrader is only active on master nodes. So data nodes can be upgraded and nothing will change to the templates. Given that new indices are created on the elected master nodes this shouldn't be an issue? Either legacy template will be applied when creating the index before upgrading elected master node or composable index / system index logic will kick after the upgrading elected master node. 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. @martijnvg ++ The |
||||
return map -> { | ||||
map.keySet().removeIf(name -> name.startsWith("watch_history_")); | ||||
// watcher migrated to using system indices so these legacy templates are not needed anymore | ||||
map.remove(".watches"); | ||||
map.remove(".triggered_watches"); | ||||
// post 7.x we moved to typeless watch-history-10 | ||||
map.remove(".watch-history-9"); | ||||
return map; | ||||
}; | ||||
} | ||||
|
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.
Security now uses a system index. FYI added this code to clean up an ancient typed index template @jkakavas