Adding settings to data streams#126947
Conversation
…/elasticsearch into adding-settings-to-data-streams
|
Pinging @elastic/es-data-management (Team:Data Management) |
lukewhiting
left a comment
There was a problem hiding this comment.
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.
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.
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.
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. |
rjernst
left a comment
There was a problem hiding this comment.
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.
why support null? seems any callers could pass empty settings?
There was a problem hiding this comment.
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.
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);
}
}
| } | ||
|
|
||
| public void testMerge() { | ||
| { |
There was a problem hiding this comment.
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. |
rjernst
left a comment
There was a problem hiding this comment.
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.
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.
the put(newSettings) can be removed since individual settings are added below, right?
There was a problem hiding this comment.
Oops, yes. That was a mistake!
lukewhiting
left a comment
There was a problem hiding this comment.
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.