Skip to content

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

Merged
merged 25 commits into from
Apr 23, 2025

Conversation

masseyke
Copy link
Member

This adds a Settings object to each DataStream. This Settings object is serialized into the cluster state, and exposed via a getSettings(), getEffectiveSettings(), and getEffectiveIndexTemplate() methods . Right now it is not used by anything, but will be in subsequent PRs.

@masseyke masseyke marked this pull request as ready for review April 17, 2025 20:37
@elasticsearchmachine elasticsearchmachine added the Team:Data Management Meta label for data/management team label Apr 17, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-data-management (Team:Data Management)

Copy link
Contributor

@lukewhiting lukewhiting left a 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 👍🏻

Comment on lines 411 to 424
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();
}
Copy link
Contributor

@lukewhiting lukewhiting Apr 22, 2025

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?

Copy link
Member Author

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.

Copy link
Contributor

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?

@lukewhiting
Copy link
Contributor

lukewhiting commented Apr 22, 2025

Also, apologies for the delay on the review here. Easter holidays in the UK made it a 4 day weekend.

@masseyke masseyke requested a review from a team as a code owner April 22, 2025 18:41
@masseyke masseyke requested a review from lukewhiting April 22, 2025 18:42
Copy link
Member

@rjernst rjernst left a 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)) {
Copy link
Member

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?

Copy link
Member Author

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);
Copy link
Member

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() {
{
Copy link
Member

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.

@masseyke
Copy link
Member Author

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?

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.

@masseyke masseyke requested a review from rjernst April 22, 2025 22:38
Copy link
Member

@rjernst rjernst left a 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)) {
Copy link
Member

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);
Copy link
Member

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?

Copy link
Member Author

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!

Copy link
Contributor

@lukewhiting lukewhiting left a 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 👍🏻

@masseyke masseyke merged commit ee2d2f3 into elastic:main Apr 23, 2025
16 of 17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Data Management/Data streams Data streams and their lifecycles >non-issue Team:Data Management Meta label for data/management team v9.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants