-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Adding settings to data streams #126947
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
Adding settings to data streams #126947
Conversation
…/elasticsearch into adding-settings-to-data-streams
Pinging @elastic/es-data-management (Team:Data Management) |
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.
A couple of comments to clarify but nothing major :-) Logic looks good and tests are robust 👍🏻
private static Settings mergeSettings(Settings originalSettings, Settings newSettings) { | ||
if (newSettings == null || Settings.EMPTY.equals(newSettings)) { | ||
return Objects.requireNonNullElse(originalSettings, Settings.EMPTY); | ||
} else if (originalSettings == null || Settings.EMPTY.equals(originalSettings)) { | ||
return newSettings; | ||
} | ||
Settings.Builder settingsBuilder = Settings.builder().put(originalSettings).put(newSettings); | ||
for (String settingName : new HashSet<>(settingsBuilder.keys())) { | ||
if (settingsBuilder.get(settingName) == null) { | ||
settingsBuilder.remove(settingName); | ||
} | ||
} | ||
return settingsBuilder.build(); | ||
} |
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'm not sure but this feels like the wrong place for this kind of method... Could the this and mergeSettingsIntoTemplate(...)
be part of the template builder or Settings object for better re-use / encapsulation?
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.
Yeah I agree. It makes me a little nervous to move them because now their behavior is not clearly just meant for data streams. See what you think of the latest commit.
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 think I do prefer it with the new layout... Is there a risk if things other than datastreams use it?
server/src/test/java/org/elasticsearch/cluster/metadata/MetadataTests.java
Show resolved
Hide resolved
Also, apologies for the delay on the review here. Easter holidays in the UK made it a 4 day weekend. |
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 only reviewed the settings infra changes.
One question about the feature in general: is there validation that settings passed in are valid index settings? Should there be an explicit list of supported settings, or filters for eg private settings? I imagine we don't want all index settings to be supported here?
* from the returned object. | ||
*/ | ||
public Settings merge(Settings newSettings) { | ||
if (newSettings == null || Settings.EMPTY.equals(newSettings)) { |
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.
why support null? seems any callers could pass empty settings?
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.
Yeah I can change it to throw NPE if the caller passes null if that's what you mean.
if (newSettings == null || Settings.EMPTY.equals(newSettings)) { | ||
return this; | ||
} | ||
Settings.Builder settingsBuilder = Settings.builder().put(this).put(newSettings); |
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.
Rather than merging and then removing nulls, could we loop over the new settings and decide whether to put or remove?
var builder = Settings.builder.put(this);
for (String key : newSettings.keys()) {
String rawValue = newSettings.get(key);
if (rawValue == null) {
builder.remove(key);
} else {
builder.put(key, rawValue);
}
}
@@ -722,4 +722,58 @@ public void testGlobValues() throws IOException { | |||
assertThat(values, contains("1")); | |||
} | |||
|
|||
public void testMerge() { | |||
{ |
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: having many blocks in a single test makes understanding what failed more difficult to understand. Prefer to have each block as a separate named test method, eg testMergeEmpty, testMergeNullValue, etc.
I assume you're talking about in DataStream? That limitation is coming in a follow-up PR (the one that adds the transport action to set the settings). And we're initially limiting it to just 2 settings (lifecycle name and number of shards), but others will probably follow. But yes it will always be a fairly small whitelist. |
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.
Looks good, minus a few additional comments.
* returned unchanged. This method never changes this object. | ||
*/ | ||
public ComposableIndexTemplate mergeSettings(Settings settings) { | ||
if (settings == null || Settings.EMPTY.equals(settings)) { |
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: null could also be removed here?
if (Settings.EMPTY.equals(newSettings)) { | ||
return this; | ||
} | ||
Settings.Builder builder = Settings.builder().put(this).put(newSettings); |
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 put(newSettings) can be removed since individual settings are added below, right?
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.
Oops, yes. That was a mistake!
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 think I like the new layout more. Looks good to me bar Ryan's outstanding points 👍🏻
This adds a Settings object to each DataStream. This Settings object is serialized into the cluster state, and exposed via a
getSettings()
,getEffectiveSettings()
, andgetEffectiveIndexTemplate()
methods . Right now it is not used by anything, but will be in subsequent PRs.