Skip to content

Introduce project-global blocks #127978

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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

pxsalehi
Copy link
Member

@pxsalehi pxsalehi commented May 9, 2025

This change introduces project global cluster blocks. It is similar to the current global block concept but scoped to only a project. i.e., for a project, there are two different globals. Cluster global and project global. This seems to fit best to the current way of how ClusterBlocks work.

This PR focuses on extending ProjectBlocks to support project global blocks, and serialization/etc changes. In a follow up PR, I'll integrate the newly added project block for project deletion in the different places where we check the blocks. (originally I had some of it here, but I've reverted those to make this easier to review).

Relates ES-11209

@pxsalehi pxsalehi added >non-issue WIP :Distributed Coordination/Distributed A catch all label for anything in the Distributed Coordination area. Please avoid if you can. labels May 9, 2025
@pxsalehi pxsalehi requested a review from ywangd May 9, 2025 16:04
@@ -106,6 +110,16 @@ public class ProjectMetadata implements Iterable<IndexMetadata>, Diffable<Projec

private final IndexVersion oldestIndexVersion;

public static final ClusterBlock PROJECT_UNDER_DELETION_BLOCK = new ClusterBlock(
Copy link
Member Author

Choose a reason for hiding this comment

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

This is the only project-global block. Most likely there will be another one later called PROJECT_RECOVERING_BLOCK used during resurrection (or also creation). The only difference being that one would be retryable but this one is not.

Copy link
Member

Choose a reason for hiding this comment

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

We should add the new project block as well. Seems odd to have a deletion block without creation.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think I'd rather wait and add that when we need it. Most likely that's the case but no rush. Having PROJECT_UNDER_DELETION_BLOCK doesn't mean we MUST have PROJECT_UNDER_CREATION_BLOCK.

Copy link
Member

Choose a reason for hiding this comment

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

Sure we can go without it first.

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.

The changes to ClusterBlocks make sense to me. For the initial PR, I'd suggest we focus on ClusterBlocks changes including serialization logic. We can change the usages in follow-ups. It may be that we can remove some of the existing or new methods towards the end once all call sites are reviewed and updated.

PS: ClusterBlock by itself does not differentiate between global and index blocks. In the same spirit, it does not need to differentiate project blocks either. Doesn't feel that great. But certainly not something to tackle now.

Comment on lines 548 to 550
static ProjectBlocks emptyMutable() {
return new ProjectBlocks(new HashMap<>(), new HashSet<>());
}
Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer to have a separate class or simply a tuple instead of having this mutable variant of ProjectBlocks.

Copy link
Member Author

@pxsalehi pxsalehi Jun 12, 2025

Choose a reason for hiding this comment

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

This is used only by the builder. It still uses some of the getter methods that ProjectBlocks provides. I have made this a private member of the builder so it is only used there.

@@ -106,6 +110,16 @@ public class ProjectMetadata implements Iterable<IndexMetadata>, Diffable<Projec

private final IndexVersion oldestIndexVersion;

public static final ClusterBlock PROJECT_UNDER_DELETION_BLOCK = new ClusterBlock(
Copy link
Member

Choose a reason for hiding this comment

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

We should add the new project block as well. Seems odd to have a deletion block without creation.

@pxsalehi
Copy link
Member Author

ClusterBlock by itself does not differentiate between global and index blocks. In the same spirit, it does not need to differentiate project blocks either. Doesn't feel that great. But certainly not something to tackle now.

Not sure, I follow. Could you elaborate? The same way an index block is a special cluster block (with a limited scope), project block is also a special kind of cluster block limited to one project.

@ywangd
Copy link
Member

ywangd commented May 14, 2025

an index block is a special cluster block (with a limited scope)

I was referring to this, i.e. an index block is a "special" ClusterBlock instead of its own separate type. There must be reasons but I am not sure what they are. So I was saying theorectically an index block can be an IndexBlock and as such a project block can be a ProjectBlock. Again, not suggesting to make the changes. Just a thought that I had when reading the code.

@pxsalehi
Copy link
Member Author

This is now ready for review. I have updated the PR description as well. I'll follow this up with a second PR. I've left only a couple of new methods in ClusterBlocks that check for project global blocks. Those were needed for some basic test here. I'll bring back or add more, in the second PR where I'll integrate checking project globals into existing actions.

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

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

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