-
Notifications
You must be signed in to change notification settings - Fork 917
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
[Non-Inclusive Language] Replace isDevClusterMaster with isDevClusterManager #1719
Conversation
link checker failure can be ignored as false positive; https://sass-lang.com/blog/libsass-is-deprecated still works fine. |
packages/osd-config/src/env.ts
Outdated
@@ -113,7 +113,7 @@ export class Env { | |||
* Indicates that this OpenSearch Dashboards instance is run as development Node Cluster master. |
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.
This comment should also be updated to match the new property name.
@@ -82,7 +82,7 @@ export async function bootstrap({ | |||
const env = Env.createDefault(REPO_ROOT, { | |||
configs, | |||
cliArgs, | |||
isDevClusterMaster: isMaster && cliArgs.dev && features.isClusterModeSupported, |
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.
is the update to isMaster
covered by a different issue/PR?
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.
Updated! I've added alias to the 'isMaster' referenced from @types/node modules.
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.
Do we need to change or use alias for isMaster
? I think it is defined in node cluster index which is not the code we write/control. If it is something we import, do we have to rename?
Reference: https://nodejs.org/docs/latest-v14.x/api/cluster.html#cluster_cluster_ismaster
Thanks Josh! Where can I find more information on the exact link that has failed the link check? |
3b9461b
to
1fe6799
Compare
Thanks for this @manasvinibs, One immediate feedback would be can we add the details that you add in the PR in the commit details? This is more inclusive on details without having to navigate to the PR. |
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.
Thanks for this! Please add support for isDevClusterMaster
and isDevClusterManager
for minor version change. Mark the master one as deprecated
and update the commit description to have more information.
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.
Thanks @manasvinibs for starting the cleaning up. I agree with Rocky that we need to keep both env.isDevClusterMaster
and env.isDevClusterManager
in env.options to not break current cx usage. Meanwhile, I think isMaster
doesn't need to rename. Because it is a function from node which is not controlled by us and is imported from node cluster index.
import { isMaster } from 'cluster';
@@ -82,7 +82,7 @@ export async function bootstrap({ | |||
const env = Env.createDefault(REPO_ROOT, { | |||
configs, | |||
cliArgs, | |||
isDevClusterMaster: isMaster && cliArgs.dev && features.isClusterModeSupported, |
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.
Do we need to change or use alias for isMaster
? I think it is defined in node cluster index which is not the code we write/control. If it is something we import, do we have to rename?
Reference: https://nodejs.org/docs/latest-v14.x/api/cluster.html#cluster_cluster_ismaster
LGTM thanks! Only thing I'm a little bit confused about is the Just another NIT, the commit message exceeds the 50 character limit. But I wouldn't block this PR for that. |
packages/osd-config/src/env.ts
Outdated
this.isDevClusterMaster = options.isDevClusterMaster; | ||
this.isDevClusterManager = options.isDevClusterManager; |
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 don't want to add too many cooks to this, because this PR is in fine shape, but I think it's worthwhile for us as a team to have a good playbook for deprecating public interfaces, because this isn't the only time we're going to have to do this (and we will still have more PRs for non-inclusive language). But generally the approach I'd favor is
- Add the new external interfaces (
isDevClusterManager
, in this case) - Mark the old interfaces deprecated (
isDevClusterMaster
) - Make all internal properties read from both, with a priority of the new interface (
this.isDevClusterManager = options.isDevClusterManager || options.isDevClusterMaster
). That way the fallback logic is not spread throughout the codebase. - Duplicate any existing tests of the old interface for the new one, so that, until we deprecate, both are covered independently. (Depending on the type of deprecation, we may also want to test that the priority order from 3. works correctly if both interfaces are used and they conflict.)
We're already doing steps 1 and 2, so the difference is in 3 and 4. There's an argument that this approach may make the eventual removal/cleanup more difficult, but I think it's a bit of a toss up. Curious for the rest of the team's perspective on the above.
For this purpose of this PR, it would mean changing this line, removing subsequent fallbacks (!(this.coreContext.env.isDevClusterMaster || this.coreContext.env.isDevClusterManager);
) and adding additional tests.
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.
My initial thought with this was if I have a new interface field introduced without having to touch the old one, felt more safer option to not break things for the downstream dependencies which might be consuming the old field as it is! But thinking through it and realizing the 'internal' tag on the internal properties, it make sense to go with 3rd point to be more clean and precise. Good call out on point 4 to include tests for the new interface property added. I can update the PR.
For this purpose of this PR, it would mean changing this line, removing subsequent fallbacks (!(this.coreContext.env.isDevClusterMaster || this.coreContext.env.isDevClusterManager);) and adding additional tests.
Yeah I think it was an issue with conflicting user name used while creating GPG key. I got this one fixed. It should be 'verified' when I update my PR. |
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
}) | ||
); | ||
|
||
expect(defaultEnv).toMatchSnapshot('env properties'); | ||
expect(defaultEnv.isDevClusterManager).toBeTruthy(); |
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.
line 62 says false but this is expected to be truthy this is because isDevClusterMaster
is true then we expect isDevClusterManager
to be true right? That's great. Can we have a test for the invert. Like isDevClusterManager
is set to true. What's the expected behavior?
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.
line 62 says false but this is expected to be truthy this is because
isDevClusterMaster
is true then we expectisDevClusterManager
to be true right? That's great. Can we have a test for the invert. LikeisDevClusterManager
is set to true. What's the expected behavior?
Updated
…evClusterManager As part of the meta issue opensearch-project/OpenSearch#2589 to track the plan and progress of applying inclusive naming across OpenSearch Repositories In this change we are deprecating the terminology "isDevClusterMaster" and adding "isDevClusterManager" for future usages. Signed-off-by: manasvinibs <[email protected]>
…evClusterManager (#1719) As part of the meta issue opensearch-project/OpenSearch#2589 to track the plan and progress of applying inclusive naming across OpenSearch Repositories In this change we are deprecating the terminology "isDevClusterMaster" and adding "isDevClusterManager" for future usages. Signed-off-by: manasvinibs <[email protected]> (cherry picked from commit 1dda730)
…evClusterManager (#1719) As part of the meta issue opensearch-project/OpenSearch#2589 to track the plan and progress of applying inclusive naming across OpenSearch Repositories In this change we are deprecating the terminology "isDevClusterMaster" and adding "isDevClusterManager" for future usages. Signed-off-by: manasvinibs <[email protected]> Signed-off-by: Manasvini B Suryanarayana <[email protected]> (cherry picked from commit 1dda730)
…evClusterManager (#1719) As part of the meta issue opensearch-project/OpenSearch#2589 to track the plan and progress of applying inclusive naming across OpenSearch Repositories In this change we are deprecating the terminology "isDevClusterMaster" and adding "isDevClusterManager" for future usages. Signed-off-by: manasvinibs <[email protected]> Signed-off-by: Manasvini B Suryanarayana <[email protected]> (cherry picked from commit 1dda730)
…evClusterManager (#1719) (#1762) As part of the meta issue opensearch-project/OpenSearch#2589 to track the plan and progress of applying inclusive naming across OpenSearch Repositories In this change we are deprecating the terminology "isDevClusterMaster" and adding "isDevClusterManager" for future usages. Signed-off-by: manasvinibs <[email protected]> Signed-off-by: Manasvini B Suryanarayana <[email protected]> (cherry picked from commit 1dda730) Co-authored-by: Manasvini B Suryanarayana <[email protected]>
…evClusterManager (opensearch-project#1719) (opensearch-project#1762) As part of the meta issue opensearch-project/OpenSearch#2589 to track the plan and progress of applying inclusive naming across OpenSearch Repositories In this change we are deprecating the terminology "isDevClusterMaster" and adding "isDevClusterManager" for future usages. Signed-off-by: manasvinibs <[email protected]> Signed-off-by: Manasvini B Suryanarayana <[email protected]> (cherry picked from commit 1dda730) Co-authored-by: Manasvini B Suryanarayana <[email protected]>
…evClusterManager (opensearch-project#1719) (opensearch-project#1762) As part of the meta issue opensearch-project/OpenSearch#2589 to track the plan and progress of applying inclusive naming across OpenSearch Repositories In this change we are deprecating the terminology "isDevClusterMaster" and adding "isDevClusterManager" for future usages. Signed-off-by: manasvinibs <[email protected]> Signed-off-by: Manasvini B Suryanarayana <[email protected]> (cherry picked from commit 1dda730) Co-authored-by: Manasvini B Suryanarayana <[email protected]>
Signed-off-by: manasvis [email protected]
Description
Coming from opensearch-project/OpenSearch#2589.
OpenSearch repository is going to replace the terminology "master" with "cluster manager".
issue: opensearch-project/OpenSearch#472 (comment), with the plan for its terminology replacement.
In this change we are replacing the instances of the terminology "isDevClusterMaster" with "isDevClusterManager".
Issues Resolved
#1690
Parent #1318
Check List
yarn test:jest
yarn test:jest_integration
yarn test:ftr