[jira] [Work logged] (ARTEMIS-3243) Enhance AMQP Mirror support with dual mirror
[ https://issues.apache.org/jira/browse/ARTEMIS-3243?focusedWorklogId=621197=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-621197 ] ASF GitHub Bot logged work on ARTEMIS-3243: --- Author: ASF GitHub Bot Created on: 09/Jul/21 22:16 Start Date: 09/Jul/21 22:16 Worklog Time Spent: 10m Work Description: clebertsuconic edited a comment on pull request #3633: URL: https://github.com/apache/activemq-artemis/pull/3633#issuecomment-877484395 chained brokers are working... (I don't intend to document about chained mirrors as I am not sure it makes sense... I added the test as a tool to verify the verifications are accurate and everything is fine). now I need to fix the isdurable parsing, the capabilities thing, and add docs.. it's getting to the end now :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 621197) Time Spent: 20h 50m (was: 20h 40m) > Enhance AMQP Mirror support with dual mirror > > > Key: ARTEMIS-3243 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3243 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.17.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.18.0 > > Time Spent: 20h 50m > Remaining Estimate: 0h > > at the current Mirror version, we can only mirror into a single direction. > With this enhancement the two (or more brokers) would be connected to each > other, each one having its own ID, and each one would send updates to the > other broker. > The outcome is that if you just transferred producers and consumers from one > broker into the other, the fallback would be automatic and simple. No need to > disable and enable mirror options. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (ARTEMIS-3243) Enhance AMQP Mirror support with dual mirror
[ https://issues.apache.org/jira/browse/ARTEMIS-3243?focusedWorklogId=621196=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-621196 ] ASF GitHub Bot logged work on ARTEMIS-3243: --- Author: ASF GitHub Bot Created on: 09/Jul/21 22:15 Start Date: 09/Jul/21 22:15 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #3633: URL: https://github.com/apache/activemq-artemis/pull/3633#issuecomment-877484395 chained brokers are working... (I don't intend to document about chained mirrors as I am not sure it makes sense... I added the test as a tool to verify the verifications are accurate and everything is fine). now I need to fix the isdurable parsing and add docs.. it's getting to the end now :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 621196) Time Spent: 20h 40m (was: 20.5h) > Enhance AMQP Mirror support with dual mirror > > > Key: ARTEMIS-3243 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3243 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.17.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.18.0 > > Time Spent: 20h 40m > Remaining Estimate: 0h > > at the current Mirror version, we can only mirror into a single direction. > With this enhancement the two (or more brokers) would be connected to each > other, each one having its own ID, and each one would send updates to the > other broker. > The outcome is that if you just transferred producers and consumers from one > broker into the other, the fallback would be automatic and simple. No need to > disable and enable mirror options. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?focusedWorklogId=621143=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-621143
]
ASF GitHub Bot logged work on AMQ-7514:
---
Author: ASF GitHub Bot
Created on: 09/Jul/21 19:18
Start Date: 09/Jul/21 19:18
Worklog Time Spent: 10m
Work Description: ehossack-aws commented on a change in pull request #679:
URL: https://github.com/apache/activemq/pull/679#discussion_r667163323
##
File path:
activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
##
@@ -2896,51 +2922,142 @@ public void setSslContext(SslContext sslContext) {
this.sslContext = sslContext;
}
+/**
+ * @deprecated AMQ-7514 in the move to inclusive nomenclature
+ */
+@Deprecated
public boolean isShutdownOnSlaveFailure() {
return shutdownOnSlaveFailure;
}
/**
+ * Configuration `shutdownOnSlaveFailure` is deprecated and will be
removed in a future release. Use `shutdownOnStandbyFailure` instead.
+ * @deprecated AMQ-7514 in the move to inclusive nomenclature
+ * @param shutdownOnSlaveFailure
* @org.apache.xbean.Property
propertyEditor="org.apache.activemq.util.BooleanEditor"
*/
+@Deprecated
public void setShutdownOnSlaveFailure(boolean shutdownOnSlaveFailure) {
this.shutdownOnSlaveFailure = shutdownOnSlaveFailure;
+this.shutdownOnStandbyFailure = shutdownOnSlaveFailure;
+LOG.warn("Configuration `shutdownOnSlaveFailure` is deprecated and
will be removed in a future release. Use `shutdownOnStandbyFailure` instead.");
}
+public boolean isShutdownOnStandbyFailure() {
+return shutdownOnStandbyFailure;
+}
+
+/**
+ * @org.apache.xbean.Property
propertyEditor="org.apache.activemq.util.BooleanEditor"
+ */
+public void setShutdownOnStandbyFailure(boolean shutdownOnStandbyFailure) {
+this.shutdownOnSlaveFailure = shutdownOnStandbyFailure;
+this.shutdownOnStandbyFailure = shutdownOnStandbyFailure;
+}
+
+/**
+ * @deprecated AMQ-7514 in the move to inclusive nomenclature
+ */
+@Deprecated
public boolean isWaitForSlave() {
return waitForSlave;
}
/**
+ * Configuration `waitForSlave` is deprecated and will be removed in a
future release. Use `waitForStandby` instead.
+ * @deprecated AMQ-7514 in the move to inclusive nomenclature
+ * @param waitForSlave
* @org.apache.xbean.Property
propertyEditor="org.apache.activemq.util.BooleanEditor"
*/
+@Deprecated
public void setWaitForSlave(boolean waitForSlave) {
this.waitForSlave = waitForSlave;
+this.waitForStandby = waitForSlave;
+LOG.warn("Configuration `waitForSlave` is deprecated and will be
removed in a future release. Use `waitForStandby` instead.");
}
+/**
+ * @deprecated AMQ-7514 in the move to inclusive nomenclature
+ */
+@Deprecated
public long getWaitForSlaveTimeout() {
return this.waitForSlaveTimeout;
}
+/**
+ * Configuration `waitForSlaveTimeout` is deprecated and will be removed
in a future release. Use `waitForStandbyTimeout` instead.
+ * @deprecated AMQ-7514 in the move to inclusive nomenclature
+ * @param waitForSlaveTimeout
+ */
+@Deprecated
public void setWaitForSlaveTimeout(long waitForSlaveTimeout) {
this.waitForSlaveTimeout = waitForSlaveTimeout;
+this.waitForStandbyTimeout = waitForSlaveTimeout;
+LOG.warn("Configuration `waitForSlaveTimeout` is deprecated and will
be removed in a future release. Use `waitForStandbyTimeout` instead.");
+
+}
+
+public boolean isWaitForStandby() {
+return waitForStandby;
}
/**
- * Get the passiveSlave
+ * @org.apache.xbean.Property
propertyEditor="org.apache.activemq.util.BooleanEditor"
+ */
+public void setWaitForStandby(boolean waitForStandby) {
+this.waitForStandby = waitForStandby;
+this.waitForSlave = waitForStandby;
+}
+
+public long getWaitForStandbyTimeout() {
+return this.waitForStandbyTimeout;
+}
+
+public void setWaitForStandbyTimeout(long waitForStandbyTimeout) {
+this.waitForSlaveTimeout = waitForStandbyTimeout;
+this.waitForStandbyTimeout = waitForStandbyTimeout;
+}
+
+/**
+ * Configuration `passiveSlave` is deprecated and will be removed in a
future release. Use `standbyInstance` instead.
+ * @deprecated AMQ-7514 in the move to inclusive nomenclature
* @return the passiveSlave
*/
+@Deprecated
public boolean isPassiveSlave() {
+LOG.warn("Configuration `passiveSlave` is deprecated and will be
removed in a future release. Use `standbyInstance` instead.");
return this.passiveSlave;
}
/**
- * Set the passiveSlave
+
[jira] [Work logged] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?focusedWorklogId=621142=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-621142
]
ASF GitHub Bot logged work on AMQ-7514:
---
Author: ASF GitHub Bot
Created on: 09/Jul/21 19:17
Start Date: 09/Jul/21 19:17
Worklog Time Spent: 10m
Work Description: ehossack-aws commented on a change in pull request #679:
URL: https://github.com/apache/activemq/pull/679#discussion_r667162869
##
File path:
activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
##
@@ -485,15 +490,15 @@ public JmsConnector removeJmsConnector(JmsConnector
connector) {
}
public void masterFailed() {
-if (shutdownOnMasterFailure) {
-LOG.error("The Master has failed ... shutting down");
+if (shutdownOnActiveFailure) {
+LOG.error("The Active has failed ... shutting down");
try {
stop();
} catch (Exception e) {
-LOG.error("Failed to stop for master failure", e);
+LOG.error("Failed to stop for active failure", e);
Review comment:
How about in the scope of this PR we add both messages, and then the
subtask is to remove the non-inclusive messages? That would support a
transition period well.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 621142)
Time Spent: 4h 20m (was: 4h 10m)
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?focusedWorklogId=621141=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-621141
]
ASF GitHub Bot logged work on AMQ-7514:
---
Author: ASF GitHub Bot
Created on: 09/Jul/21 19:16
Start Date: 09/Jul/21 19:16
Worklog Time Spent: 10m
Work Description: ehossack-aws commented on a change in pull request #679:
URL: https://github.com/apache/activemq/pull/679#discussion_r667162581
##
File path:
activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
##
@@ -485,15 +490,15 @@ public JmsConnector removeJmsConnector(JmsConnector
connector) {
}
public void masterFailed() {
-if (shutdownOnMasterFailure) {
-LOG.error("The Master has failed ... shutting down");
+if (shutdownOnActiveFailure) {
+LOG.error("The Active has failed ... shutting down");
Review comment:
I did a 'find references' search and yeah, you're right @mattrpav. I
think this is also relevant in the discussion about active/passive/standby. It
seems reasonable in the scope of this change rather than renaming to actually
remove those methods/concepts. Then there is no need to consider the 'existing'
terminology.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 621141)
Time Spent: 4h 10m (was: 4h)
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378237#comment-17378237 ] Étienne Hossack commented on AMQ-7514: -- [~cshannon] shifting to the dev list makes sense to me, especially given the scope of the decision is widened to include Artemis. Unless someone objects, I will summarize and link the discussion later today in a message to the dev list? > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 4h > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378231#comment-17378231 ] Justin Bertram commented on AMQ-7514: - bq. The scope of this ticket is a terminology change for the ActiveMQ code base... I appreciate that this is in the AMQ Jira project, but it is an issue that affects both the classic and Artemis brokers. bq. ActiveMQ does not have the concept around node meaning when it comes to primary/standby (formerly master/slave). I understand that and I certainly grant that it's not exactly the same as the semantics in Artemis. However, even in the case of ActiveMQ classic you configure the brokers as _something_ and that something needs a name. Since it is indeterminate maybe it's called "a primary/standby pair" (i.e. a combination of the new nouns). Then at runtime one is the primary and one is the standby based on who won the race to acquire the lock. Either way, there is a configured state and a runtime condition that must be clearly defined and this definition should use terms which are consistent across brokers. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 4h > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378215#comment-17378215 ] Christopher L. Shannon commented on AMQ-7514: - I agree more so with going the primary/secondary or leader/follower etc route vs active/passive because of the reasons specified by Gary and Michael. The most important thing is consistency so whatever is done needs to be the same across ActiveMQ 5.x and Artemis to avoid confusion. Also, I think this conversation should probably be held on the dev list going forward so we can discuss and have an official vote on terms we want to use going forward. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 4h > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378141#comment-17378141 ] Domenico Francesco Bruscino commented on AMQ-7514: -- I would also vote for 'primary', it seems to match all requirements described above. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 4h > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARTEMIS-2974) Audit logger can print wrong user info
[ https://issues.apache.org/jira/browse/ARTEMIS-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378087#comment-17378087 ] ASF subversion and git services commented on ARTEMIS-2974: -- Commit 4c06d447fdb0bb9117b5a93ab745d8dc52b72642 in activemq-artemis's branch refs/heads/main from gtully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4c06d44 ] ARTEMIS-2974 - fix up the regexp used in the test to match to the end > Audit logger can print wrong user info > -- > > Key: ARTEMIS-2974 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2974 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.17.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When dispatching messages to consumer the audit logger may print the wrong > user info. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378061#comment-17378061 ] Gary Tully commented on AMQ-7514: - my vote would be to replace 'master' with 'primary'. primary can have many meanings and be both a noun or adjective[1]. I think this looseness helps here. [1] https://www.google.com/search?q=primary+definition it does not imply secondary but can work with it, similarly with backup it can work, or with replica too. they can all work with a 'primary'. Even in a single broker world it can be the 'primary'. I think there could even be multiple primary brokers (that are peers) and there can be sharding or sharing or whatever, it won't effect that they are primary (important) brokers. The primary has exclusive access to a journal. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 4h > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?focusedWorklogId=620967=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-620967
]
ASF GitHub Bot logged work on AMQ-7514:
---
Author: ASF GitHub Bot
Created on: 09/Jul/21 12:59
Start Date: 09/Jul/21 12:59
Worklog Time Spent: 10m
Work Description: mattrpav commented on a change in pull request #679:
URL: https://github.com/apache/activemq/pull/679#discussion_r666927309
##
File path:
activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
##
@@ -485,15 +490,15 @@ public JmsConnector removeJmsConnector(JmsConnector
connector) {
}
public void masterFailed() {
-if (shutdownOnMasterFailure) {
-LOG.error("The Master has failed ... shutting down");
+if (shutdownOnActiveFailure) {
+LOG.error("The Active has failed ... shutting down");
try {
stop();
} catch (Exception e) {
-LOG.error("Failed to stop for master failure", e);
+LOG.error("Failed to stop for active failure", e);
Review comment:
Updating log messages is tricky, since it can break monitoring in
not-so-easy-to-upgrade ways. I think this should be a sub-task conversation on
the parent ticket.
##
File path:
activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
##
@@ -485,15 +490,15 @@ public JmsConnector removeJmsConnector(JmsConnector
connector) {
}
public void masterFailed() {
-if (shutdownOnMasterFailure) {
-LOG.error("The Master has failed ... shutting down");
+if (shutdownOnActiveFailure) {
+LOG.error("The Active has failed ... shutting down");
Review comment:
This group of methods is never read anywhere by the code base. My
understanding is that they are legacy hold-over from early replication approach
that has been removed long ago. I do not see any reason to deprecate them.
Given that we have agreed to make major breaking changes in 5.17.x (remove
leveldb), I believe we can safely remove these methods in this pass.
We should not be adding new terms or concepts that do not apply to the code
base in this pass.
##
File path:
activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
##
@@ -2896,51 +2922,142 @@ public void setSslContext(SslContext sslContext) {
this.sslContext = sslContext;
}
+/**
+ * @deprecated AMQ-7514 in the move to inclusive nomenclature
+ */
+@Deprecated
public boolean isShutdownOnSlaveFailure() {
return shutdownOnSlaveFailure;
}
/**
+ * Configuration `shutdownOnSlaveFailure` is deprecated and will be
removed in a future release. Use `shutdownOnStandbyFailure` instead.
+ * @deprecated AMQ-7514 in the move to inclusive nomenclature
+ * @param shutdownOnSlaveFailure
* @org.apache.xbean.Property
propertyEditor="org.apache.activemq.util.BooleanEditor"
*/
+@Deprecated
public void setShutdownOnSlaveFailure(boolean shutdownOnSlaveFailure) {
this.shutdownOnSlaveFailure = shutdownOnSlaveFailure;
+this.shutdownOnStandbyFailure = shutdownOnSlaveFailure;
+LOG.warn("Configuration `shutdownOnSlaveFailure` is deprecated and
will be removed in a future release. Use `shutdownOnStandbyFailure` instead.");
}
+public boolean isShutdownOnStandbyFailure() {
+return shutdownOnStandbyFailure;
+}
+
+/**
+ * @org.apache.xbean.Property
propertyEditor="org.apache.activemq.util.BooleanEditor"
+ */
+public void setShutdownOnStandbyFailure(boolean shutdownOnStandbyFailure) {
+this.shutdownOnSlaveFailure = shutdownOnStandbyFailure;
+this.shutdownOnStandbyFailure = shutdownOnStandbyFailure;
+}
+
+/**
+ * @deprecated AMQ-7514 in the move to inclusive nomenclature
+ */
+@Deprecated
Review comment:
This method is never called in the code base. My understanding is that
it was kept to not break configurations from the long-gone active-active
replication. I would contend that since we have agreed to remove leveldb from
5.17.x and there are no planned usages for these metods, that this method (and
related ones) could safely be removed instead of deprecated.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 620967)
Time Spent: 4h (was: 3h 50m)
> Replace racially charged terms throughout source code, comments and
> documentation
>
[jira] [Commented] (ARTEMIS-3372) Openwire - deleting a queue leaves consumers in limbo
[ https://issues.apache.org/jira/browse/ARTEMIS-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378020#comment-17378020 ] ASF subversion and git services commented on ARTEMIS-3372: -- Commit 3961fd1cf2837a43fc245cddbbaf4a5f81a4f8f8 in activemq-artemis's branch refs/heads/main from gtully [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=3961fd1 ] ARTEMIS-3372 - ensure test verification happens after expected failover event such that expected message is not tracked as a duplicate > Openwire - deleting a queue leaves consumers in limbo > - > > Key: ARTEMIS-3372 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3372 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: OpenWire >Affects Versions: 2.17.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.18.0 > > Time Spent: 50m > Remaining Estimate: 0h > > openwire consumers are in limbo if a queue is deleted by a management > operation. > with activemq5 - any message sent will recreate the queue and the consumers > will resume. > however with Artemis, the send it to an address, independent of the consumer > queue. The send will continue to drop messages till the binding/queue is > recreated. > Any openwire consumer disconnect (typical on queue deletion) needs to be > implemented as connection error/fail to force a possible client failover > event and a recreation of the queue/binding. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377910#comment-17377910 ] Michael Andre Pearce commented on AMQ-7514: --- [~ehossack] i appreciate that. This said just because something works somewhere else, within a given context doesn't mean it automatically works else where. Like wise i really would like to avoid renaming the meanings of everything. The word "active" has existing terminology and meaning, along side what master / slave means especially in Artemis. And want to avoid overusing that word to mean different and new things. I would really like to see/hear alternative proposals from yourselves, rather than simply pushing only the nomenclature you use at AWS. As i keep calling out, there is many alternatives and well adopted alternatives to Master / Slave terminology, lets explore and propose some alternatives, that do not clash with existing terminology and naming used / historic ones, to avoid confusions. I'm open to alternatives, im just a bit against s/master/active/g in our code bases, due to existing meanings and historic usage within the project. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377886#comment-17377886 ] Étienne Hossack commented on AMQ-7514: -- [~michael.andre.pearce], my opinions of the nomenclature expressed here are purely my own. My callout of what AWS uses was simply a data point to illustrate that it is viable to use Active/Standby and cause no confusion. I would definitely prefer a decision come collaboratively in the spirit of the Apache community. [~tetlucas] and myself are passionate about both inclusivity and open source, and wanted to help drive the conversation through the phases of this plan. If that’s being taken as Amazon MQ trying to dictate anything then we would be more than happy to recuse ourselves from this conversation and let the community at large decide how to proceed. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377869#comment-17377869 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:16 AM: But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. You have to remember that we are supporting user transitioning from Classic to Artemis, as such yes terminology alignment is important! Which does mean we need to cater holistically as a project, that means catering for both Classic and Artemis. was (Author: michael.andre.pearce): But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. You have to remember that we are supporting user transitioning from Classic to Artemis, as such yes terminology alignment is important! Which does mean we need to cater holistically as a project, that means catering for both Classic and Artemis > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377869#comment-17377869 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:15 AM: But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. You have to remember that we are supporting user transitioning from Classic to Artemis, as such yes terminology alignment is important! Which does mean we need to cater holistically as a project, that means catering for both Classic and Artemis was (Author: michael.andre.pearce): But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. You have to remember that we are supporting user transitioning from Classic to Artemis, as such yes Terminology Alignment is important! > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377869#comment-17377869 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:14 AM: But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. You have to remember that we are supporting user transitioning from Classic to Artemis, as such yes Terminology Alignment is important! was (Author: michael.andre.pearce): But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377869#comment-17377869 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:13 AM: But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, especially when there history to the existing terminology, it is an Apache project NOT an AWS one.. was (Author: michael.andre.pearce): But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, it is an Apache project NOT an AWS one.. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377869#comment-17377869 ] Michael Andre Pearce commented on AMQ-7514: --- But the point is there is that history and also your rephrase for artemis is a bit of a WTF still. Simply lets just avoid the issue, by using different terminology, theres plenty of available replacement words.. As noted both [~ehossack] and [~tetlucas] i understand per comment on the PR you raised [~ehossack] you both work at AWS and active is used to replace master at AWS, but i really dont want a specific vendor's preference to naming their services dictate what an Apache project gets to call their, it is an Apache project NOT an AWS one.. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377867#comment-17377867
]
Lucas Tétreault commented on AMQ-7514:
--
{quote}The point is alignment with the replacement of the words Master and
Slave for both Brokers.
{quote}
Maybe the deployment modes are different enough that aligning the terminology
doesn't make sense?
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377864#comment-17377864 ] Étienne Hossack edited comment on AMQ-7514 at 7/9/21, 7:06 AM: --- Regarding your concerns [~michael.andre.pearce] for ActiveMQ 5.17+ as those are the ones currently in question, since leveldb has been removed, I don't think we have to worry about that confusion! Yes it could change in the future, but the discussion is for right now, and we can't really predict the future it's a good path forward in my opinion. For Artemis I hear your concerns about states and designations. So rather than introduce something new, maybe keeping the current live/backup as is used in the docs is best? The config can reference Active/Replica or whichever as needed to determine the intent of the node. I'll reiterate that "primary" or "leader" are moderately confusing in the context of multiple HA pairs within an Artemis cluster. I don't believe any of the terms in the linked article are any clearer. Your sentence "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" can be written as: "When an Active node fails the Replica takes over [accepting traffic]. If you have configured your broker with the 'allow-failback' option, when the original Active is restarted, the Replica will resume replication and the Active node will accept traffic." I believe the confusion in your sentence comes from the capitalization and referencing "failback" as concept before defining what that actually means in the context of this HA pair. In general I believe a broker user/documentation reader does not need to be aware of a formal state in this context, and the implicit meaning in a sentence can suffice (serving traffic). edit: It might even reduce the cognitive load, since it's one less concept to have to learn. was (Author: ehossack): Regarding your concerns [~michael.andre.pearce] for ActiveMQ 5.17+ as those are the ones currently in question, since leveldb has been removed, I don't think we have to worry about that confusion! Yes it could change in the future, but the discussion is for right now, and we can't really predict the future it's a good path forward in my opinion. For Artemis I hear your concerns about states and designations. So rather than introduce something new, maybe keeping the current live/backup as is used in the docs is best? The config can reference Active/Replica or whichever as needed to determine the intent of the node. I'll reiterate that "primary" or "leader" are moderately confusing in the context of multiple HA pairs within an Artemis cluster. I don't believe any of the terms in the linked article are any clearer. Your sentence "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" can be written as: "When an Active node fails the Replica takes over [accepting traffic]. If you have configured your broker with the 'allow-failback' option, when the original Active is restarted, the Replica will resume replication and the Active node will accept traffic." I believe the confusion in your sentence comes from the capitalization and referencing "failback" as concept before defining what that actually means in the context of this HA pair. In general I believe a broker user/documentation reader does not need to be aware of a formal state in this context, and the implicit meaning in a sentence can suffice (serving traffic). > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:05 AM:
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{code:java}
{code}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
was (Author: michael.andre.pearce):
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{code:java}
{code}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
It
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:04 AM:
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{code:java}
{code}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
It
was (Author: michael.andre.pearce):
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{{
}}
{{}}
{{}}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
It
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377864#comment-17377864 ] Étienne Hossack commented on AMQ-7514: -- Regarding your concerns [~michael.andre.pearce] for ActiveMQ 5.17+ as those are the ones currently in question, since leveldb has been removed, I don't think we have to worry about that confusion! Yes it could change in the future, but the discussion is for right now, and we can't really predict the future it's a good path forward in my opinion. For Artemis I hear your concerns about states and designations. So rather than introduce something new, maybe keeping the current live/backup as is used in the docs is best? The config can reference Active/Replica or whichever as needed to determine the intent of the node. I'll reiterate that "primary" or "leader" are moderately confusing in the context of multiple HA pairs within an Artemis cluster. I don't believe any of the terms in the linked article are any clearer. Your sentence "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" can be written as: "When an Active node fails the Replica takes over [accepting traffic]. If you have configured your broker with the 'allow-failback' option, when the original Active is restarted, the Replica will resume replication and the Active node will accept traffic." I believe the confusion in your sentence comes from the capitalization and referencing "failback" as concept before defining what that actually means in the context of this HA pair. In general I believe a broker user/documentation reader does not need to be aware of a formal state in this context, and the implicit meaning in a sentence can suffice (serving traffic). > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:03 AM:
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back. The broker
service still has the capability to re-add it because whilst level db was
removed seperation between master and slave and if passive is still in broker
service, so re-adding a different replication solution without issue.
e.g. this is sample classic config that was for pure master slave, back in
leveldb time.
{{
}}
{{}}
{{}}
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
It
was (Author: michael.andre.pearce):
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back.
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 7:00 AM:
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back.
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
was (Author: michael.andre.pearce):
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back.
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:58 AM:
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back.
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
{code:java}
public boolean isPassiveSlave() {
return this.passiveSlave;
}
{code}
was (Author: michael.andre.pearce):
The point is alignment with the replacement of the words Master and Slave for
both Brokers. Theres no point having one terminology for one and another for
the other. Like wise Classic has had the concepts of replicated setup before,
and tbh in future i could always see another attempt to try re-add, so master
slave for the node designation even in classic would come back.
Further to this point, even now today still theres code in classic where we
have "Passive Slave" where passive is the state.
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:57 AM: The point is alignment with the replacement of the words Master and Slave for both Brokers. Theres no point having one terminology for one and another for the other. Like wise Classic has had the concepts of replicated setup before, and tbh in future i could always see another attempt to try re-add, so master slave for the node designation even in classic would come back. Further to this point, even now today still theres code in classic where we have "Passive Slave" where passive is the state. was (Author: michael.andre.pearce): The point is alignment with the replacement of the words Master and Slave for both Brokers. Theres no point having one terminology for one and another for the other. Like wise Classic has had the concepts of replicated setup before, and tbh in future i could always see another attempt to try re-add, so master slave for the node designation even in classic would come back. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377861#comment-17377861 ] Michael Andre Pearce commented on AMQ-7514: --- The point is alignment with the replacement of the words Master and Slave for both Brokers. Theres no point having one terminology for one and another for the other. Like wise Classic has had the concepts of replicated setup before, and tbh in future i could always see another attempt to try re-add, so master slave for the node designation even in classic would come back. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:53 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. The Slave never becomes master and a master never becomes a slave, they keep their designations, their state simply changes to becoming "Active" For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, and becomes and Active Replica but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby or Leader / Follower, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby/Follower has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby/Follower has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually network replication based master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. The Slave never becomes master and a master never becomes a slave, they keep their designations, their state simply changes to becoming "Active" For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader /
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377860#comment-17377860
]
Lucas Tétreault commented on AMQ-7514:
--
[~michael.andre.pearce] and[~jbertram]
It seems to me like this sentence from Justin neatly summarizes why you are
both opposed to the "active/standby" terminology.
{quote} If we don't have clear ways to discuss both the configured state and
runtime condition of the nodes it will be difficult to properly document and
troubleshoot.
{quote}
If that is the case, then I don't really understand the argument since Classic
doesn't have the concept of "configured state" as Matt said. We really are just
talking about the current runtime condition of the nodes aren't we?
> Replace racially charged terms throughout source code, comments and
> documentation
> -
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
>Reporter: Bruce Snyder
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:49 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. The Slave never becomes master and a master never becomes a slave, they keep their designations, their state simply changes to becoming "Active" For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby or Leader / Follower, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby/Follower has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby/Follower has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually network replication based master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby or Leader / Follower, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:47 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby or Leader / Follower, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby/Follower has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby/Follower has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually network replication based master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:45 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a "Passive Slave" in the broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually network replication based master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:43 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually network replication based master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:43 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of brokers(classic) or in clustering (artemis) where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually replication base master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:42 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of clusters where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually replication base master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:41 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had additional terms/use for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of clusters where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually replication base master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:39 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the nodes current state, especially in artemis and prior in classic with leveldb and replicated kahadb previously. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of clusters where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually replication base master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of clusters where you can have multi masters. And
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:38 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Leader and Standby has no connotation that you only have one master like you do with the word primary, e.g. like in network of clusters where you can have multi masters. And like wise Standby has no connotation you can only have 1 like with the word secondary, also it avoids the confusion where not using replication defining a slave as replica, when not actually replication base master slave setup. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 >
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:34 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Leader / Standby, but im for any alternative (Primary / Replica) thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Primary / Standby, but im for any alternative thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:33 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have node states and node designations, the node designations being master or slave, which you actively define the node type in the configuration, with either having the possibility to becoming "Active" which means the node currently servicing, we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Primary / Standby, but im for any alternative thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Primary / Standby, but im for any alternative thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:30 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] I personally like Primary / Standby, but im for any alternative thats NOT simply not using the words Active/Passive for a nodes designation, its the nodes state, which we have historically used the word active and passive, to define and describe the state. Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] Why make a terminology problem, if we don't have to. > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:28 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] Why make a terminology problem, if we don't have to. was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:28 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:26 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about Active MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove
[jira] [Comment Edited] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:25 AM: I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] For one second ignoring Artemis and just talking about Active MQ5 Classic, we actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] was (Author: michael.andre.pearce): I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] We actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ >
[jira] [Commented] (AMQ-7514) Replace racially charged terms throughout source code, comments and documentation
[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377842#comment-17377842 ] Michael Andre Pearce commented on AMQ-7514: --- I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram] We actually had addtional terms for master and slave when we had leveldb with its "pure master slave" and like wise back with replicated kaha db, the broker service master and slave actually was around the nodes role, and then it became active when it took over. To this point we actually still have the slave in what we call a passiveSlave in the. broker service where the Slave is still not activated. Regarding Replication in Artemis again, we have states, this is determined master or slave, which you actively define the node type in the configuration, with either the node becoming "Active", we even have the concepts of failback to master for predominate master setups. For this reason i think we really need to avoid the words "Active" or "Slave" for defining a node, we use it to mean the current state of a node, if we start overloading the term as you suggest we will end up with phrases like "When an Active node fails the Replica takes over, but if you have fail back to Active configured when the Active node is restarted the Active Replica will failback to the Active node and it will become Active again" Like seriously WTF.. its a terminology disaster. There is plenty of alternatives to the words Master/Slave that avoid the word "Active" so lets simply avoid the problem.. [https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now] > Replace racially charged terms throughout source code, comments and > documentation > - > > Key: AMQ-7514 > URL: https://issues.apache.org/jira/browse/AMQ-7514 > Project: ActiveMQ > Issue Type: Task >Reporter: Bruce Snyder >Priority: Major > Time Spent: 3h 50m > Remaining Estimate: 0h > > Given the racial charged nature of certain terms in today's world, we must > pull together to create a plan for changing any such terms throughout all the > ActiveMQ projects and in the git repos themselves. > > Example: [https://activemq.apache.org/masterslave.html] > > Here are just a few terms that should be changed: * The following terms are > being targeted for change: > * > ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup' > ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist' > and 'denylist' > * Rename all the git 'master' branches to the term 'main' > Proposal notes from activemq-dev mailing list > Phase 1: > 1. Deprecate terms such as ‘master’ and ’slave > 2. log.warn any configuration change notifications > 3. Provide compatibility under the covers for deprecated terms > 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis > 5. Notify users in an announcement and provide a conversion HOWTO > Phase 2: > 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’ > in ‘x.y.z’ is minor version number) > New terms: > a. For shared storage: ‘active’ and ’standby’ > b. For replication: ‘primary’ and ‘replica' > c. For 'white list' and 'blacklist': 'allow list' and 'deny list' > For example: > ‘master’ -> ‘active’ > ’slave’ -> ’standby' -- This message was sent by Atlassian Jira (v8.3.4#803005)
