Adding actions to get and update data stream mappings

[masseyke]

This follows #129787 by adding transport actions to get and update data stream mappings. This is the 2nd of 3 PRs that will add mapping overrides to data streams. The 3rd one will add the rest actions.

[elasticsearchmachine]

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

[Copilot]

Pull Request Overview

This PR introduces transport actions and cluster service support to retrieve and update data stream mappings, along with associated request/response classes, tests, and security privileges.

• Added new operator privileges for the get and update data stream mappings APIs
• Implemented GetDataStreamMappingsAction and UpdateDataStreamMappingsAction (actions, transport, cluster service methods)
• Added wire serialization and XContent tests for both get and update mapping requests and responses

Reviewed Changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
x-pack/plugin/security/qa/operator-privileges-tests/src/javaRestTest/java/org/elasticsearch/xpack/security/operator/Constants.java	Added new operator privileges for data stream mapping endpoints
server/src/test/java/org/elasticsearch/action/datastreams/UpdateDataStreamMappingsActionResponseTests.java	Tests for the update mappings response serialization and XContent
server/src/test/java/org/elasticsearch/action/datastreams/UpdateDataStreamMappingsActionRequestTests.java	Wire serialization tests for the update mappings request
server/src/test/java/org/elasticsearch/action/datastreams/GetDataStreamMappingsActionTests.java	XContent tests for get mappings response
server/src/test/java/org/elasticsearch/action/datastreams/GetDataStreamActionTests.java	Extended DataStreamInfo XContent tests to include mappings
server/src/main/java/org/elasticsearch/cluster/metadata/MetadataDataStreamsService.java	Cluster‐state logic for update mappings tasks
server/src/main/java/org/elasticsearch/action/datastreams/UpdateDataStreamMappingsAction.java	Defined new update mappings action, request, and response
server/src/main/java/org/elasticsearch/action/datastreams/GetDataStreamMappingsAction.java	Defined new get mappings action and response
modules/data-streams/src/main/java/org/elasticsearch/datastreams/action/TransportUpdateDataStreamMappingsAction.java	Transport action for updating mappings
modules/data-streams/src/main/java/org/elasticsearch/datastreams/action/TransportGetDataStreamMappingsAction.java	Transport action for retrieving mappings
modules/data-streams/src/main/java/org/elasticsearch/datastreams/DataStreamsPlugin.java	Registered new mapping actions in the plugin

Comments suppressed due to low confidence (2)

server/src/main/java/org/elasticsearch/action/datastreams/GetDataStreamMappingsAction.java:112

• [nitpick] The lambda parameter DataStreamMappingsResponse shadows the type name and begins with an uppercase letter; rename it to a lowercase identifier like resp to improve readability.

                dataStreamMappingsResponses.stream().map(DataStreamMappingsResponse -> (ToXContent) DataStreamMappingsResponse).iterator(),

modules/data-streams/src/main/java/org/elasticsearch/datastreams/action/TransportUpdateDataStreamMappingsAction.java:9

• The new transport action for updating data stream mappings lacks dedicated tests; consider adding unit or integration tests to cover its behavior.

package org.elasticsearch.datastreams.action;

[lukewhiting]

Looks good (baring outstanding co-pilot stuff)!

I have 👍🏻ed on the assumption the lack of tests for the two new actions is because you aim to do YAML REST tests in the next PR for them.

[masseyke]

I have 👍🏻ed on the assumption the lack of tests for the two new actions is because you aim to do YAML REST tests in the next PR for them.

Yes, I have not found a great way to test these without the yaml rest tests. I considered just adding all the rest stuff in this PR but it's already a large PR.

[masseyke]

I have 👍🏻ed on the assumption the lack of tests for the two new actions is because you aim to do YAML REST tests in the next PR for them.

Yes, I have not found a great way to test these without the yaml rest tests. I considered just adding all the rest stuff in this PR but it's already a large PR.

On second thought, I realized an integration test would not be bad at all, and added TransportUpdateDataStreamMappingsActionIT. In doing that, I realized that DataStreamTests had been broken for over a year (and was masking a bug in my code). So that's in now, too.

[nielsbauman]

Two small drive-by comments for multi-project related things :)

[nielsbauman]

While this works because the IndexNameExpressionResolver makes use of the project resolver as well, it's a bit more explicit if we pass a ProjectMetadata in directly.

Suggested change

	clusterService.state(),
	project.metadata(),

[nielsbauman]

Same here about passing a ProjectMetadata instead of a ClusterState.

[nielsbauman]

We should avoid creating a ProjectState unnecessarily.

Suggested change

	state.projectState(projectResolver.getProjectId()).metadata(),
	projectResolver.getProjectMetadata(state),

But see my next comment before committing this - we'll want to extract this as a variable.

[masseyke]

Oops I didn't see these last couple. Will put them in a follow-up PR

[nielsbauman]

We can also avoid constructing the ProjectState here, but we also shouldn't use the project resolver here, as this is executing async and might thus have a different thread context. We should pass the project ID from masterOperation.

[masseyke]

I think we have to construct a ProjectState here, right (using a stored-off projectId)? The alternative is to grab the ProjectMetadata in the earlier thread and store it off, but that ProjectMetadata could be out of date at the time this thread is executed.

[nielsbauman]

We can do

clusterService.state().metadata().getProject(projectId)

sorry for not explicitly mentioning that before