Introduce project-global blocks #127978
Introduce project-global blocks #127978
Conversation
pxsalehi
added
>non-issue
WIP
:Distributed Coordination/Distributed
| @@ -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( | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
We should add the new project block as well. Seems odd to have a deletion block without creation.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Sure we can go without it first.
There was a problem hiding this comment.
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.
| static ProjectBlocks emptyMutable() { | ||
| return new ProjectBlocks(new HashMap<>(), new HashSet<>()); | ||
| } |
There was a problem hiding this comment.
I'd prefer to have a separate class or simply a tuple instead of having this mutable variant of ProjectBlocks.
| @@ -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( | |||
There was a problem hiding this comment.
We should add the new project block as well. Seems odd to have a deletion block without creation.
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. |
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. |
This is a draft to show how I plan to add a project block. 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
ClusterBlockswork.As a general rule, I've went with: if a block check looks at a specific index then the project global block is not relevant similar to how cluster block is not. If a check in
ClusterBlocksalso checks the global block then probably it should check also the project block (depending on if the caller is project-aware). These two rules don't 100% always hold, so I've left some comments in the code to make it easier to track where the changes might matter. Obviously the comments will be removed!There is no serialization/diff changes here. Once we agree on the current changes, I can add them, clean up and add tests.
Relates ES-11209