Skip to content

Conversation

@pxsalehi
Copy link
Member

@pxsalehi pxsalehi commented Jun 16, 2025

This PR updates some of the existing checks for cluster blocks to also consider project global blocks. It adds a few project-aware flavour of existing methods in ClusterBlocks. globalBlockedRaiseException is the mostly used one. I've updated only some of the obvious ones here.
Follow up to #127978
Relates ES-11209

@pxsalehi pxsalehi added >non-issue :Distributed Coordination/Distributed A catch all label for anything in the Distributed Coordination area. Please avoid if you can. labels Jun 16, 2025
}
}

public void globalBlockedRaiseException(ProjectId projectId, ClusterBlockLevel level) throws ClusterBlockException {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

globalBlockedRaiseException(ClusterBlockLevel level) (the non-project-aware flavour of this) has some 200 callers mostly Transport actions. These seem to be the bulk of what it takes to integrate the project global cluster blocks into existing checks for blocks. I've been through half of them and have update some based on the following.

  • If a TransportAction's corresponding RestAction has a @ServerlessScope(Scope.PUBLIC) annotation, then I'd make its block check use this project aware version. In most cases, the action is already project aware or at least has a ProjectResolver, in some cases, I've added that as well.
  • Some of the Scope.INTERNAL ones, probably still need to consider project block, e.g. TransportDeleteDataStreamLifecycleAction, TransportForceMergeAction. I've updated some as well.
  • There are also some TransportActions that don't necessarily have a RestAction, but to me they seem to need to be project-aware w.r.t. checking blocks e.g. some of the persistent task related stuff such as CompletionPersistentTaskAction. I haven't dived into those.

I think properly going through all of these, is a rather big effort since in many cases, the relavent code is not project-aware and it is not clear to me if it will be. So my plan is to go through the second half of these as well and do the obvious ones. And open a ticket to come back to this. I assume we'd need to communicate this as part of "how to make things project-aware" when teams are doing their chuck of MP-compatibility.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

globalBlockedRaiseException(ClusterBlockLevel level) (the non-project-aware flavour of this) has some 200 callers mostly Transport actions.

I think you mean globalBlockedException(ClusterBlockLevel).

CompletionPersistentTaskAction

This one is tricky since persistent task can be both cluster and project scoped. I think we might need something like the follows

if (projectResolver.supportsMultipleProjects() == false) {
    return state.blocks().globalBlockedException(ClusterBlockLevel.METADATA_WRITE);
} else {
    final var projectId = projectResolver.getProjectId();
    if (projectId == null || ProjectId.DEFAULT.equals(projectId)) {
        return state.blocks().globalBlockedException(ClusterBlockLevel.METADATA_WRITE);
    } else {
        return state.blocks().globalBlockedException(projectId, ClusterBlockLevel.METADATA_WRITE);
    }
}

We can iterate on this with a separate PR.

And open a ticket to come back to this

I agree. We don't own every action that uses the blocks. It makes sense to raise the awareness for other teams.

@pxsalehi pxsalehi requested a review from ywangd June 16, 2025 15:41
@pxsalehi pxsalehi marked this pull request as ready for review June 16, 2025 15:41
@elasticsearchmachine elasticsearchmachine added the Team:Distributed Coordination Meta label for Distributed Coordination team label Jun 16, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination)

Copy link
Member

@ywangd ywangd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Mostly minor comments except the one suggests leaving UpdatePersistentTaskStatusAction out of this PR.

}
}

public void globalBlockedRaiseException(ProjectId projectId, ClusterBlockLevel level) throws ClusterBlockException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

globalBlockedRaiseException(ClusterBlockLevel level) (the non-project-aware flavour of this) has some 200 callers mostly Transport actions.

I think you mean globalBlockedException(ClusterBlockLevel).

CompletionPersistentTaskAction

This one is tricky since persistent task can be both cluster and project scoped. I think we might need something like the follows

if (projectResolver.supportsMultipleProjects() == false) {
    return state.blocks().globalBlockedException(ClusterBlockLevel.METADATA_WRITE);
} else {
    final var projectId = projectResolver.getProjectId();
    if (projectId == null || ProjectId.DEFAULT.equals(projectId)) {
        return state.blocks().globalBlockedException(ClusterBlockLevel.METADATA_WRITE);
    } else {
        return state.blocks().globalBlockedException(projectId, ClusterBlockLevel.METADATA_WRITE);
    }
}

We can iterate on this with a separate PR.

And open a ticket to come back to this

I agree. We don't own every action that uses the blocks. It makes sense to raise the awareness for other teams.

Comment on lines +350 to 352
clusterState.blocks().globalBlockedRaiseException(projectResolver.getProjectId(), ClusterBlockLevel.READ);

ProjectState projectState = projectResolver.getProjectState(clusterState);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit:

Suggested change
clusterState.blocks().globalBlockedRaiseException(projectResolver.getProjectId(), ClusterBlockLevel.READ);
ProjectState projectState = projectResolver.getProjectState(clusterState);
ProjectState projectState = projectResolver.getProjectState(clusterState);
clusterState.blocks().globalBlockedRaiseException(projectState.projectId(), ClusterBlockLevel.READ);

protected ClusterBlockException checkBlock(Request request, ClusterState state) {
// Cluster is not affected but we look up repositories in metadata
return state.blocks().globalBlockedException(ClusterBlockLevel.METADATA_WRITE);
return state.blocks().globalBlockedException(projectResolver.getProjectId(), ClusterBlockLevel.METADATA_WRITE);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is similar to CompletionPersistentTaskAction in that persistent tasks can be either project or cluster scoped. I'd leave this to a different PR that focuses on persistent tasks. What do you think?

@pxsalehi
Copy link
Member Author

Thanks, Yang. I'll merge this.

  • I'll go through the rest of the TransportActions to see if there are obvious ones that need to be updated and would open a second PR for that.
  • Opened ES-12113 to go through persistent task framework in a separate ticket.
  • I've update the Guide to Multi-Project Development. So any of the potential remaining cases would be done by the specific area teams.

@pxsalehi pxsalehi enabled auto-merge (squash) June 17, 2025 09:50
@pxsalehi pxsalehi disabled auto-merge June 17, 2025 09:51
@pxsalehi pxsalehi enabled auto-merge (squash) June 17, 2025 09:53
@pxsalehi pxsalehi merged commit d3d10c2 into elastic:main Jun 17, 2025
25 of 27 checks passed
pxsalehi added a commit that referenced this pull request Jun 18, 2025
kderusso pushed a commit to kderusso/elasticsearch that referenced this pull request Jun 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Distributed Coordination/Distributed A catch all label for anything in the Distributed Coordination area. Please avoid if you can. >non-issue Team:Distributed Coordination Meta label for Distributed Coordination team v9.1.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants