-
Notifications
You must be signed in to change notification settings - Fork 25.3k
Infrastructure for assuming cluster features in the next major version #118143
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
Changes from all commits
49f359d
885e8de
efad7f3
5544bd4
b604511
0930466
733f2dd
7a1dc02
812c280
3889d4e
86e0171
a2c71a7
4b94b1a
0939c46
c84b2e6
1ea0d67
7a12300
9d19288
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 |
---|---|---|
@@ -0,0 +1,5 @@ | ||
pr: 118143 | ||
summary: Infrastructure for assuming cluster features in the next major version | ||
area: "Infra/Core" | ||
type: feature | ||
issues: [] |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,10 +15,17 @@ | |
* A feature published by a node. | ||
* | ||
* @param id The feature id. Must be unique in the node. | ||
* @param assumedAfterNextCompatibilityBoundary | ||
* {@code true} if this feature is removed at the next compatibility boundary (ie next major version), | ||
* and so should be assumed to be true for all nodes after that boundary. | ||
*/ | ||
public record NodeFeature(String id) { | ||
public record NodeFeature(String id, boolean assumedAfterNextCompatibilityBoundary) { | ||
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. Naming might need a bit of work 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 struggle coming up with something better... 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. Though next major is not correct in the context of serverless... 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. Yeah, exactly, it was |
||
|
||
public NodeFeature { | ||
Objects.requireNonNull(id); | ||
} | ||
|
||
public NodeFeature(String id) { | ||
this(id, 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.
Stumbled over
remove
incanRemoveAssumedFeatures
, that was confusing to me and I kept looking for where we remove those. Maybe turning it around makes it easier to understand:canAssumeRemovedFeatures
Uh oh!
There was an error while loading. Please reload this page.
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.
That's not quite right though, its not that all features that are missing can be assumed, it's that the features that this ES has marked as assumed can be taken as being met in a node with this version, regardless of whether they're published by the node or not.
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.
Yes, you're right 👍
If we can find something better than remove, it'd be great, but certainly not worth delaying this further.
canInferAssumedFeatures
,canExpectAssumedFeatures
,canSkipAssumedFeatures
Or more targeting the versioning side of this:
hasPassedNextCompatiblityBoundary
or similar.