-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Deprecate public methods and variables that contain 'master' terminology in class 'NoMasterBlockService' and 'MasterService' #4006
Conversation
…ogy in class NoMasterBlockService and MasterService Signed-off-by: Tianli Feng <[email protected]>
Gradle Check (Jenkins) Run Completed with:
|
Codecov Report
@@ Coverage Diff @@
## main #4006 +/- ##
============================================
- Coverage 70.51% 70.34% -0.17%
+ Complexity 56800 56711 -89
============================================
Files 4573 4573
Lines 273476 273485 +9
Branches 40101 40102 +1
============================================
- Hits 192844 192387 -457
- Misses 64420 64870 +450
- Partials 16212 16228 +16
Help us with your feedback. Take ten seconds to tell us how you rate us. |
Signed-off-by: Tianli Feng <[email protected]>
Gradle Check (Jenkins) Run Completed with:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR largely LGTM. I have one question before giving a full approval. I'd like us to be thoughtful about public static
modifiers because they will get used / abused by extensions if they are available and not marked as @internal
. Do we want these static variables to be used in extensions? I understand we might need to retain public
for internal purposes but if we want to guardrail them against extensions we should apply the @opensearch.internal
javadoc tag to signal they should not be used outside of core.
@@ -76,6 +76,19 @@ public class NoClusterManagerBlockService { | |||
EnumSet.of(ClusterBlockLevel.METADATA_WRITE) | |||
); | |||
|
|||
/** @deprecated As of 2.2, because supporting inclusive language, replaced by {@link #NO_CLUSTER_MANAGER_BLOCK_ID} */ | |||
@Deprecated | |||
public static final int NO_MASTER_BLOCK_ID = NO_CLUSTER_MANAGER_BLOCK_ID; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we holding on to these because there are plugins or extensions that use this static variable outside of core?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nknize Thank you so much for your review! 👍
I didn't check whether the public static
variables are used in plugins or not. My idea was to keep the compatibility in minor versions, such as 2.x
, for all methods and variables that will be renamed.
This change is going to be backported into 2.x
branch, so I can't break compatibility for any public
method or variable.
After doing a search in GitHub, looks like the variable NO_MASTER_BLOCK_ID
is only used in this repository.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't find usage of "NO_MASTER_BLOCK_" outside of the OpenSearch repo, so I think all of these are fair game for removal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even changing the public variable name is a technical breaking change, after backporting this PR to 2.x
branch, is it fine to rename here directly instead of marking as deprecated first?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tlfeng you are taking the conservative approach and, IMHO, this is a good move. The inherited code base is sloppy wrt visibility modifiers and javadocs and this causes issues and confusion with extensions and external plugins. We're trying to fix that on OpenSearch to support our micro-repository project design.
I presume these variables are "internal use only" thus safe to unilaterally refactor w/o compatibility support. However, since they have no markings I think we should treat them as if an extension is using them and follow the deprecation process. I don't believe we have have this formally written out so I'll jot the process down here (you're largely already following this):
- Add deprecation annotation
- Update javadocs to communicate usage permissions (
@opensearch.internal
,@opensearch.experimental
, or@opensearch.api
) - Add deprecation messages (including the logger, if possible or necessary)
- Commit deprecation and backport
- Open a new PR that removes in main or refactors visibility modifier
Thoughts? /cc @andrross
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nknize That is definitely the conservative approach and probably the right way to go. It's one extra PR with some trivial removals/changes so that's minimal extra work without having to worry about breaking our promise not to introduce breaking changes in a minor version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So then I think the only change to this PR would be to add @opensearch.internal
to the new refactored variables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add javadocs w/ @opensearch.internal
to the new refactored variables to signal they are internal use only and could change at any time w/o bwc guarantees. I give one suggested example in the review.
@@ -76,6 +76,19 @@ public class NoClusterManagerBlockService { | |||
EnumSet.of(ClusterBlockLevel.METADATA_WRITE) | |||
); | |||
|
|||
/** @deprecated As of 2.2, because supporting inclusive language, replaced by {@link #NO_CLUSTER_MANAGER_BLOCK_ID} */ | |||
@Deprecated | |||
public static final int NO_MASTER_BLOCK_ID = NO_CLUSTER_MANAGER_BLOCK_ID; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So then I think the only change to this PR would be to add @opensearch.internal
to the new refactored variables.
public static final int NO_MASTER_BLOCK_ID = 2; | ||
public static final ClusterBlock NO_MASTER_BLOCK_WRITES = new ClusterBlock( | ||
NO_MASTER_BLOCK_ID, | ||
public static final int NO_CLUSTER_MANAGER_BLOCK_ID = 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public static final int NO_CLUSTER_MANAGER_BLOCK_ID = 2; | |
/** | |
* Ordinal ID used to block when no cluser manager is available | |
* @opensearch.internal | |
*/ | |
public static final int NO_CLUSTER_MANAGER_BLOCK_ID = 2; |
Of course feel free to update the javadoc to something more clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nknize Got it. Thanks a lot for your detailed explanation! In yesterday I didn't realize that you would like me to add @opensearch.internal
annotation on the variable.
I've got a question, since the whole class has been marked with @opensearch.internal
:
Line 47 in 00db112
* @opensearch.internal |
Is that necessary to mark the variable? or you just want to emphasize it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh! Good point! No I think that covers it. Thx for pointing it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nknize No problem! Thank you for your suggestion on the action we should make to avoid the public API abuse, this will be a good example. 😄👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thx for iterating on this!
…ogy in class 'NoMasterBlockService' and 'MasterService' (#4006) Deprecates public methods and variables that contain 'master' terminology in class NoMasterBlockService and MasterService. Unit tests are also added to ensure consistency with the new naming. Signed-off-by: Tianli Feng <[email protected]> (cherry picked from commit e65aaca)
…ogy in class 'NoMasterBlockService' and 'MasterService' (#4006) (#4038) To support inclusive language, the `master` terminology is going to be replaced by `cluster manager` in the code base. - Deprecated public methods and variables in class `NoMasterBlockService` and `MasterService`, and created alternative methods or variables. - A unit test is added to validate the change of thread name that identifies the thread running update task for MasterService. List of public methods and variables that deprecated. In class `NoMasterBlockService`: ``` int NO_MASTER_BLOCK_ID ClusterBlock NO_MASTER_BLOCK_WRITES ClusterBlock NO_MASTER_BLOCK_ALL ClusterBlock NO_MASTER_BLOCK_METADATA_WRITES ClusterBlock getNoMasterBlock() ``` In class `MasterService`: ``` String MASTER_UPDATE_THREAD_NAME boolean assertMasterUpdateThread() boolean assertNotMasterUpdateThread(String reason) ``` Signed-off-by: Tianli Feng <[email protected]> (cherry picked from commit e65aaca)
Description
To support inclusive language, the
master
terminology is going to be replaced bycluster manager
in the code base.NoMasterBlockService
andMasterService
, and created alternative methods or variables.List of public methods and variables that deprecated.
In class
NoMasterBlockService
:In class
MasterService
:Issues Resolved
A part of issue #3543
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.