[jira] [Commented] (LUCENE-10471) Increase the number of dims for KNN vectors to 2048

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17577849#comment-17577849
 ] 

Marcus Eagan commented on LUCENE-10471:
---

[~michi] You are free to increase the dimension limit as it is a static 
variable and Lucene is your oyster. However, [~ehatcher] has Seared in my mind 
that this a long term fork ok Lucene is a bad idea for many reasons.

#[~rcmuir] I agree with you on "whatever shitty models." They are here, and 
more are coming. With respect to the vector API, Oracle is doing an interesting 
bit of work in Open JDK 17 to improve their vector API. They've added support 
for Intel's short vector math library, which will improve. The folk at OpenJDK 
exploit the Panama APIs. There are several hardware accelerations they are yet 
to exploit, and many operations will fall back to scalar code. 

My argument is for increasing the limit of dimensions is not to suggest that 
there is a better fulcrum in the performance tradeoff balancer, but that more 
users testing Lucene is good for improving the feature.

Open AI's Da Vinci is one such model but not the only

I've had customers ask for 4096 based on the performance they observe with 
question an answering. I'm waiting on the model and will  share when I know. If 
customers want to introduce rampant numerical errors in their systems, there is 
little we can do for them. Don't take my word on any of this yet. I need to 
bring data and complete evidence. I'm asking my customers why they cannot do 
dimensional reduction.

> Increase the number of dims for KNN vectors to 2048
> ---
>
> Key: LUCENE-10471
> URL: https://issues.apache.org/jira/browse/LUCENE-10471
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Mayya Sharipova
>Priority: Trivial
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The current maximum allowed number of dimensions is equal to 1024. But we see 
> in practice a couple well-known models that produce vectors with > 1024 
> dimensions (e.g 
> [mobilenet_v2|https://tfhub.dev/google/imagenet/mobilenet_v2_035_224/feature_vector/1]
>  uses 1280d vectors, OpenAI / GPT-3 Babbage uses 2048d vectors). Increasing 
> max dims to `2048` will satisfy these use cases.
> I am wondering if anybody has strong objections against this.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8637) WeightedSpanTermExtractor unnexessarily enforces rewrite for some SpanQueiries

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426406#comment-17426406
 ] 

Marcus Eagan commented on LUCENE-8637:
--

[~gol...@detego-software.de] Can you check if it breaks unit tests? Do you know 
how to run the whole suite?

> WeightedSpanTermExtractor unnexessarily enforces rewrite for some SpanQueiries
> --
>
> Key: LUCENE-8637
> URL: https://issues.apache.org/jira/browse/LUCENE-8637
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Affects Versions: 7.4, 7.3.1, 7.5, 7.6
>Reporter: Christoph Goller
>Priority: Minor
>  Labels: patch
> Attachments: WeightedSpanTermExtractor.java
>
>
> Method mustRewriteQuery(SpanQuery) returns true for SpanPositionCheckQuery, 
> SpanContainingQuery, SpanWithinQuery, and SpanBoostQuery, however, these 
> queries do not require rewriting. One effect of this is e.g. that 
> UnifiedHighlighter does not work with OffsetSource Postings and switches to 
> Analysis which of course has consequences for performance.
> I attach a patch for lucene version 7.6.0. I have not checked whether it 
> breaks existing unit tests.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7321) Character Mapping

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17356136#comment-17356136
 ] 

Marcus Eagan commented on LUCENE-7321:
--

Hi [~iprovalo] I'm curious if you have been maintaining this patch through 
version `8` for your company? If so, do you want to revive this discussion?

> Character Mapping
> -
>
> Key: LUCENE-7321
> URL: https://issues.apache.org/jira/browse/LUCENE-7321
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.6.1, 5.4.1, 6.0, 6.0.1
>Reporter: Ivan Provalov
>Priority: Minor
>  Labels: patch
> Fix For: 6.0.1
>
> Attachments: CharacterMappingComponent.pdf, LUCENE-7321.patch
>
>
> One of the challenges in search is recall of an item with a common typing 
> variant.  These cases can be as simple as lower/upper case in most languages, 
> accented characters, or more complex morphological phenomena like prefix 
> omitting, or constructing a character with some combining mark.  This 
> component addresses the cases, which are not covered by ASCII folding 
> component, or more complex to design with other tools.  The idea is that a 
> linguist could provide the mappings in a tab-delimited file, which then can 
> be directly used by Solr.
> The mappings are maintained in the tab-delimited file, which could be just a 
> copy paste from Excel spreadsheet.  This gives the linguists the opportunity 
> to create the mappings, then for the developer to include them in Solr 
> configuration.  There are a few cases, when the mappings grow complex, where 
> some additional debugging may be required.  The mappings can contain any 
> sequence of characters to any other sequence of characters.
> Some of the cases I discuss in detail document are handling the voiced vowels 
> for Japanese; common typing substitutions for Korean, Russian, Polish; 
> transliteration for Polish, Arabic; prefix removal for Arabic; suffix folding 
> for Japanese.  In the appendix, I give an example of implementing a Russian 
> light weight stemmer using this component.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8626) standardise test class naming

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17297815#comment-17297815
 ] 

Marcus Eagan commented on LUCENE-8626:
--

Thank you Christine for wrapping this up.  Looks like it was open for 859d 47m. 

> standardise test class naming
> -
>
> Key: LUCENE-8626
> URL: https://issues.apache.org/jira/browse/LUCENE-8626
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, 
> SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch
>
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> This was mentioned and proposed on the dev mailing list. Starting this ticket 
> here to start to make it happen?
> History: This ticket was created as 
> https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got 
> JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-15158) Error when upgrading from Solr 8.0.0 to 8.5.2

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17297016#comment-17297016
 ] 

Marcus Eagan commented on SOLR-15158:
-

Hi [~amitguptag] I suspect this issue could be caused by a variety of factors. 
One that comes to mind immediately is improper formatting of a config file, 
likely JSON because of the comma and AUTHORIZATION being called out in the 
error message.

Can you double check the integrity of your security.json file? Ensure it is 
formatted appropriately. 

Furthermore, there were a few significant changes from 8 to 8.5. I would start 
there, though.

> Error when upgrading from Solr 8.0.0 to 8.5.2
> -
>
> Key: SOLR-15158
> URL: https://issues.apache.org/jira/browse/SOLR-15158
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 8.5.2
>Reporter: Amit Gupta
>Priority: Blocker
>  Labels: 8.5.2, solr, upgrade
>
> I am trying to upgrade our tech stack from 8.0.0 to 8.5.2. The cofiguration 
> work until the first time the ersver is rebooted. Then solr stops working 
> with below error. The exact same config works with solr 8.0.0 without issues.
> Extract  from solr.log:
> 021-02-15 19:04:52.922 INFO (main) [ ] o.a.s.c.ZkContainer Zookeeper 
> client=10.201.52.56:2181,10.201.52.169:2181,10.201.52.136:2181
> 2021-02-15 19:04:52.940 INFO (main) [ ] o.a.s.c.c.ConnectionManager Waiting 
> for client to connect to ZooKeeper
> 2021-02-15 19:04:52.949 INFO (zkConnectionManagerCallback-9-thread-1) [ ] 
> o.a.s.c.c.ConnectionManager zkClient has connected
> 2021-02-15 19:04:52.949 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client is 
> connected to ZooKeeper
> 2021-02-15 19:04:53.047 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could not 
> start Solr. Check solr/home property and the logs
> 2021-02-15 19:04:53.077 ERROR (main) [ ] o.a.s.c.SolrCore 
> null:org.noggit.JSONParser$ParseException: Unexpected comma: 
> char=,,position=324 AFTER='QuEFwT7s= 
> nlE/oRd/BIthqBP8UY1yFiu6Betb7xDoyTPFD3AxaUo="}} },' BEFORE=' 
> "authorization":{ "class":"solr.R'
>  at org.noggit.JSONParser.err(JSONParser.java:452)
>  at org.noggit.JSONParser.next(JSONParser.java:1013)
>  at org.noggit.JSONParser.nextEvent(JSONParser.java:1073)
>  at org.noggit.ObjectBuilder.checkEOF(ObjectBuilder.java:52)
>  at org.noggit.ObjectBuilder.getValStrict(ObjectBuilder.java:76)
>  at org.apache.solr.common.util.Utils.fromJSON(Utils.java:270)
>  at org.apache.solr.common.util.Utils.fromJSON(Utils.java:256)
>  at 
> org.apache.solr.common.cloud.ZkStateReader.getSecurityProps(ZkStateReader.java:1274)
>  at 
> org.apache.solr.common.cloud.ZkStateReader.createClusterStateWatchersAndUpdate(ZkStateReader.java:527)
>  at org.apache.solr.cloud.ZkController.init(ZkController.java:902)
>  at org.apache.solr.cloud.ZkController.(ZkController.java:472)
>  at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115)
>  at org.apache.solr.core.CoreContainer.load(CoreContainer.java:663)
>  at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:263)
>  at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:183)
>  at org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
>  at 
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
>  at 
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
>  at 
> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
>  at 
> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
>  at 
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658)
>  at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
>  at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360)
>  at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
>  at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
>  at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
>  at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
>  at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
>  at 
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
>  at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
>  at 
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513)
>  at 
> 

[jira] [Commented] (LUCENE-9431) UnifiedHighlighter: Make WEIGHT_MATCHES the default

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-9431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280397#comment-17280397
 ] 

Marcus Eagan commented on LUCENE-9431:
--

Hi Yury,

Are you still working on this ticket?

> UnifiedHighlighter: Make WEIGHT_MATCHES the default
> ---
>
> Key: LUCENE-9431
> URL: https://issues.apache.org/jira/browse/LUCENE-9431
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: David Smiley
>Priority: Blocker
> Fix For: master (9.0)
>
>
> This mode uses Lucene's modern mechanism of exposing information that 
> previously required complicated highlighting machinery.  It's also likely to 
> generally work better out-of-the-box and with custom queries.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eagan updated SOLR-14702:

Description: 
Every time I read _master_ and _slave_, I get pissed.

I think about the last and only time I remember visiting my maternal great 
grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
he lost his legs, and then he was back to being a sharecropper somehow after 
the war. Crazy, I know. I don't know if the world still called his job 
sharecropping in 1993, but he was basically a slave—in America. He lived in the 
same shack that his father, and his grandfather (born a slave) lived in down in 
Alabama. Believe it or not, my dad's grandfather was actually born a slave, 
freed shortly after birth by his owner father. I never met him, though. He died 
in the 40s.

Anyway, I cannot police all terms in the repo and do not wish to. This 
master/slave shit is archaic and misleading on technical grounds. Thankfully, 
there's only a handful of files in code and documentation that still talk about 
masters and slaves. We should replace all of them.

There are so many ways to reword it. In fact, unless anyone else objects or 
wants to do the grunt work to help my stress levels, I will open the pull 
request myself in effort to make this project and community more inviting to 
people of all backgrounds and histories. We can have leader/follower, or 
primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
garbage. 

 

  was:
Every time I read _master_ and _slave_, I get pissed.

I think about the last and only time I remember visiting my maternal great 
grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
he lost his legs, and then he was back to being a sharecropper somehow after 
the war. Crazy, I know. I don't know if the world still called his job 
sharecropping in 1993, but he was basically a slave—in America. He lived in the 
same shack that his father, and his grandfather (born a slave) lived in down in 
Alabama. Believe it or not, my dad's (born in 1926) grandfather was actually 
born a slave, freed shortly after birth by his owner father. I never met him, 
though. He died in the 40s.

Anyway, I cannot police all terms in the repo and do not wish to. This 
master/slave shit is archaic and misleading on technical grounds. Thankfully, 
there's only a handful of files in code and documentation that still talk about 
masters and slaves. We should replace all of them.

There are so many ways to reword it. In fact, unless anyone else objects or 
wants to do the grunt work to help my stress levels, I will open the pull 
request myself in effort to make this project and community more inviting to 
people of all backgrounds and histories. We can have leader/follower, or 
primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
garbage. 

 


> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Fix For: 8.7, master (9.0)
>
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 17h
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's grandfather was actually born a 
> slave, freed shortly after birth by his owner father. I never met him, 
> though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (LUCENE-8626) standardise test class naming

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268864#comment-17268864
 ] 

Marcus Eagan commented on LUCENE-8626:
--

I've added the final batch of standardized tests.  No more inconsistencies.

https://github.com/apache/lucene-solr/pull/2220

> standardise test class naming
> -
>
> Key: LUCENE-8626
> URL: https://issues.apache.org/jira/browse/LUCENE-8626
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Priority: Major
> Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, 
> SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> This was mentioned and proposed on the dev mailing list. Starting this ticket 
> here to start to make it happen?
> History: This ticket was created as 
> https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got 
> JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8626) standardise test class naming

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224350#comment-17224350
 ] 

Marcus Eagan commented on LUCENE-8626:
--

[I added another 36 tests to this 
ticket|https://github.com/apache/lucene-solr/pull/2053]

> standardise test class naming
> -
>
> Key: LUCENE-8626
> URL: https://issues.apache.org/jira/browse/LUCENE-8626
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Priority: Major
> Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, 
> SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> This was mentioned and proposed on the dev mailing list. Starting this ticket 
> here to start to make it happen?
> History: This ticket was created as 
> https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got 
> JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17211773#comment-17211773
 ] 

Marcus Eagan commented on SOLR-14708:
-

That’s right, users may experience issues with the cache. Maybe we should be 
explicit about cache as the potential cause of issues?

> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
> that we remove master/slave terminology from the Solr codebase. Now that's 
> complete, we need to ensure it is backward compatible to support rolling 
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
> upgrade Solr. 
> Tomas offered a helpful path in a now abandoned PR: 
> {quote}One way to get back compatibility and rolling upgrades could be to 
> make 9.x code be able to read previous formats, but write new format, and 
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a 
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x 
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept 
> parameter values for the legacy verbiage, or leader/follower, but only write 
> leader/follower. We need to then make 8_x work in the inverse way. The burden 
> here is not on that proposal or on the code in my view. Instead, the burden 
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three 
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and 
> the leader node is forced to fail and then is brought back.
> Case C: 
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a 
> rolling upgrade and a follower needs to become leader. 
> I know haven't listed all possible scenarios or everything that could happen. 
> Please let me know if you have thoughts or guidance on how best to accomplish 
> this work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14777) Chipping Away at Test Ignore in the Reference Impl Part 1

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14777:
---

 Summary: Chipping Away at Test Ignore in the Reference Impl Part 1
 Key: SOLR-14777
 URL: https://issues.apache.org/jira/browse/SOLR-14777
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (9.0)
Reporter: Marcus Eagan


I want to contribute to the future of Lucene and Solr :)! For me, one action 
would be to help advance [~markrmil...@gmail.com]'s Reference Implementation 
with the dirty work we all hate doing. Hopefully, I'll open up a few PRs 
against his branch that improve test coverage. I'll keep my commits and my PRs 
atomic to facilitate quicker review because I know we are all busy and need to 
be able to understand what's happening quickly. I want to be a leader in this 
community one day and it is incumbent on those who aspire to be leaders to do 
the things that no one else uninspired (and probably more talented) would want 
to do first.

Wish me luck and stay tuned!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14726) Streamline getting started experience

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182825#comment-17182825
 ] 

Marcus Eagan commented on SOLR-14726:
-

[~arafalov] Whatever committer(s) own the getting developer experience for 
developers should seriously consider taking ownership of this problem. V2 
implies that the community should use it soon if not now. As someone who is 
regularly using the project, it is confusing even for me. 

Who is that person, or who are those people?


> Streamline getting started experience
> -
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: newdev
> Attachments: yasa-http.png
>
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our 
> best practices, that should also be followed in production. I have following 
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page 
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should 
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation 
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that 
> it can be easily executed from Google Colaboratory. Here's an example: 
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial 
> can be executed from those tools. Except for starting Solr, all other steps 
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.), 
> configsets from Solr's distribution (instead let the examples refer to them 
> from github)
> # Remove the post tool from Solr, curl should suffice.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14726) Streamline getting started experience

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182825#comment-17182825
 ] 

Marcus Eagan edited comment on SOLR-14726 at 8/23/20, 7:01 PM:
---

[~arafalov] Whichever committer(s) own the getting developer experience for 
developers should seriously consider taking ownership of this problem. V2 
implies that the community should use it soon if not now. As someone who is 
regularly using the project, it is confusing even for me. 

Who is that person, or who are those people?



was (Author: marcussorealheis):
[~arafalov] Whatever committer(s) own the getting developer experience for 
developers should seriously consider taking ownership of this problem. V2 
implies that the community should use it soon if not now. As someone who is 
regularly using the project, it is confusing even for me. 

Who is that person, or who are those people?


> Streamline getting started experience
> -
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: newdev
> Attachments: yasa-http.png
>
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our 
> best practices, that should also be followed in production. I have following 
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page 
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should 
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation 
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that 
> it can be easily executed from Google Colaboratory. Here's an example: 
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial 
> can be executed from those tools. Except for starting Solr, all other steps 
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.), 
> configsets from Solr's distribution (instead let the examples refer to them 
> from github)
> # Remove the post tool from Solr, curl should suffice.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14705) Release Smoke Test Script Shows Unusable JDK Version

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17182044#comment-17182044
 ] 

Marcus Eagan commented on SOLR-14705:
-

Agree




> Release Smoke Test Script Shows Unusable JDK Version
> 
>
> Key: SOLR-14705
> URL: https://issues.apache.org/jira/browse/SOLR-14705
> Project: Solr
>  Issue Type: Bug
>  Components: release-scripts
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Minor
>
> The script works fine, but the help text in the smoke test script needs to be 
> replaced. Should be Java 8 for now and moved to Java 11 when the community is 
> preparing to release Solr 9. :)
> Here's the output:
> usage: smokeTestRelease.py [-h] [--tmp-dir PATH] [--not-signed]
>[--local-keys PATH] [--revision REVISION]
>[--version X.Y.Z(-ALPHA|-BETA)?]
>[--test-java9 JAVA9_HOME] [--download-only]
>url ...
>  
> I wouldn't touch Java 9 with a ten foot pole, and nor should new releases.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14753) More Consistent Thread Safety Annotations.

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17178093#comment-17178093
 ] 

Marcus Eagan commented on SOLR-14753:
-

[~anshum] Can you take a look and merge this PR. It's very simple. 

> More Consistent Thread Safety Annotations.
> --
>
> Key: SOLR-14753
> URL: https://issues.apache.org/jira/browse/SOLR-14753
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This is a simple but important step to adopt more consistent thread safety 
> annotations originally created by Mark Miller and added into Solr by Anshum 
> from an internal Apple fork.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14731) Make use of @SolrSingleThreaded Implementation

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17178092#comment-17178092
 ] 

Marcus Eagan commented on SOLR-14731:
-

This PR makes use of an improved name, but will cause pre-commit to fail until 
it succeeds.

> Make use of @SolrSingleThreaded Implementation 
> ---
>
> Key: SOLR-14731
> URL: https://issues.apache.org/jira/browse/SOLR-14731
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
> Environment: {color:red}colored text{color}
>Reporter: Marcus Eagan
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> This change may viewed as minor today, but making a habit of this annotation 
> should prove very beneficial in the long run when I forget things that I 
> worked on 3 years ago, 3 years from now.
> This is my first attempt to leverage [~anshum]'s work from: 
> https://issues.apache.org/jira/browse/SOLR-13998
> [~anshum] please let me know if I am screwing something up! :) and thanks for 
> adding this a while back.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14753) More Consistent Thread Safety Annotations.

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14753:
---

 Summary: More Consistent Thread Safety Annotations.
 Key: SOLR-14753
 URL: https://issues.apache.org/jira/browse/SOLR-14753
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (9.0)
Reporter: Marcus Eagan


This is a simple but important step to adopt more consistent thread safety 
annotations originally created by Mark Miller and added into Solr by Anshum 
from an internal Apple fork.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13998) Add thread safety annotation to classes

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17178079#comment-17178079
 ] 

Marcus Eagan commented on SOLR-13998:
-

Great. Thanks [~cpoerschke] and [~dsmiley].

> Add thread safety annotation to classes
> ---
>
> Key: SOLR-13998
> URL: https://issues.apache.org/jira/browse/SOLR-13998
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: master (9.0), 8.4
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Add annotations that can be used to mark classes as thread safe / single 
> threaded in Solr.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14731) Make use of @SolrSingleThreaded Implementation

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176145#comment-17176145
 ] 

Marcus Eagan commented on SOLR-14731:
-

this is an annotation to denote that this class is single-threaded.

> Make use of @SolrSingleThreaded Implementation 
> ---
>
> Key: SOLR-14731
> URL: https://issues.apache.org/jira/browse/SOLR-14731
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
> Environment: {color:red}colored text{color}
>Reporter: Marcus Eagan
>Priority: Major
>
> This change may viewed as minor today, but making a habit of this annotation 
> should prove very beneficial in the long run when I forget things that I 
> worked on 3 years ago, 3 years from now.
> This is my first attempt to leverage [~anshum]'s work from: 
> https://issues.apache.org/jira/browse/SOLR-13998
> [~anshum] please let me know if I am screwing something up! :) and thanks for 
> adding this a while back.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14731) Make use of @SolrSingleThreaded Implementation

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14731:
---

 Summary: Make use of @SolrSingleThreaded Implementation 
 Key: SOLR-14731
 URL: https://issues.apache.org/jira/browse/SOLR-14731
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
 Environment: {color:red}colored text{color}
Reporter: Marcus Eagan


This change may viewed as minor today, but making a habit of this annotation 
should prove very beneficial in the long run when I forget things that I worked 
on 3 years ago, 3 years from now.

This is my first attempt to leverage [~anshum]'s work from: 
https://issues.apache.org/jira/browse/SOLR-13998

[~anshum] please let me know if I am screwing something up! :) and thanks for 
adding this a while back.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13998) Add thread safety annotation to classes

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176101#comment-17176101
 ] 

Marcus Eagan commented on SOLR-13998:
-

[~anshum] that makes sense. I didn't realized it was cherry picked from his 
branch. Adding that context into the PR comments before merging might help 
people to understand the rationale and give them a place to look to contribute.

I'll be sure to add it in future classes because I have recently written a 
single threaded class. If I knew about this, I would have used it. In any 
event, I am happy it's there if it useful for others. 

> Add thread safety annotation to classes
> ---
>
> Key: SOLR-13998
> URL: https://issues.apache.org/jira/browse/SOLR-13998
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: master (9.0), 8.4
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Add annotations that can be used to mark classes as thread safe / single 
> threaded in Solr.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13998) Add thread safety annotation to classes

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176102#comment-17176102
 ] 

Marcus Eagan commented on SOLR-13998:
-

[~anshum] can you link to the branch Mark shared?

> Add thread safety annotation to classes
> ---
>
> Key: SOLR-13998
> URL: https://issues.apache.org/jira/browse/SOLR-13998
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: master (9.0), 8.4
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Add annotations that can be used to mark classes as thread safe / single 
> threaded in Solr.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8626) standardise test class naming

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176068#comment-17176068
 ] 

Marcus Eagan commented on LUCENE-8626:
--

Great ideas [~dweiss] and [~dsmiley]!

> standardise test class naming
> -
>
> Key: LUCENE-8626
> URL: https://issues.apache.org/jira/browse/LUCENE-8626
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Priority: Major
> Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, 
> SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch
>
>
> This was mentioned and proposed on the dev mailing list. Starting this ticket 
> here to start to make it happen?
> History: This ticket was created as 
> https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got 
> JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13998) Add thread safety annotation to classes

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17176031#comment-17176031
 ] 

Marcus Eagan commented on SOLR-13998:
-

Hi [~anshum] I'm working on some janitorial work in the project, and I noticed 
that you added annotations, but did not implement them. Thus, this title is 
misleading, and one of the annotations added here has only been used once since 
you added this PR in December. 

I'm curious what you had in mind for the SolrSingleThreaded annotation and why 
didn't you actually add the annotation anywhere.

Futhermore, would you like help to expand the usage of this class, or do you 
feel it was hastily added and is a waste of time? I doubt the latter because 
there should be quite a few obvious uses for this code. However, I will defer 
to you since you added it. I'm looking through all the PRs of this year to 
create an inventory of the sort of code and behavior (in code) that I'd hope to 
steward the community away from. I have a few items so far, but this is one I 
was not totally sure about because of its sparsity and how long it had been 
just sitting in the repo (7 months before any usage at all). 

I also don't know if the way Solr operates is, we just throw tools into the 
toolbox and if someone uses them one day, great. If not, someone will one day. 
Ideally, if we bring something to the project we ourselves would at least use 
it because we see value in it. I'm an outsider, learning everyday, and hoping 
to improve the project. 

> Add thread safety annotation to classes
> ---
>
> Key: SOLR-13998
> URL: https://issues.apache.org/jira/browse/SOLR-13998
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Major
> Fix For: master (9.0), 8.4
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Add annotations that can be used to mark classes as thread safe / single 
> threaded in Solr.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14726) Streamline getting started experience

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17174436#comment-17174436
 ] 

Marcus Eagan commented on SOLR-14726:
-

bq. My experience from delivering the Solr version of Think Like a Relevance 
Engineer is that MANY MANY people aren't able to install python. They may be on 
Windows, they may not have "Developer" permissions, they may have Python 2 
versus 3, or it's just not something they use at all.

Yeah, if you're not a Python engineer I have watched very skilled engineers 
struggle with Python and understanding pip and virtual environments. I would 
vote absolutely against adding Python even though it is my favorite and 
strongest language by far. 

> Streamline getting started experience
> -
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: newdev
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our 
> best practices, that should also be followed in production. I have following 
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page 
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should 
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation 
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that 
> it can be easily executed from Google Colaboratory. Here's an example: 
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial 
> can be executed from those tools. Except for starting Solr, all other steps 
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.), 
> configsets from Solr's distribution (instead let the examples refer to them 
> from github)
> # Remove the post tool from Solr, curl should suffice.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14726) Streamline getting started experience

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17174434#comment-17174434
 ] 

Marcus Eagan commented on SOLR-14726:
-

bq. If we could rely on Python and felt free to ask people to install things, I 
would lean towards HTTPie instead of curl: https://httpie.org/

HTTPie is amazing but still fringe in terms of adoption. Everyone knows cURL.

I think that we should be able to point people to public datasets that are 
hosted elsewhere (maybe by one of us) rather than shipping Solr with example 
data. I'm happy to donate a public data repository for 10 years. 



> Streamline getting started experience
> -
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: newdev
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our 
> best practices, that should also be followed in production. I have following 
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page 
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should 
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation 
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that 
> it can be easily executed from Google Colaboratory. Here's an example: 
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial 
> can be executed from those tools. Except for starting Solr, all other steps 
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.), 
> configsets from Solr's distribution (instead let the examples refer to them 
> from github)
> # Remove the post tool from Solr, curl should suffice.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14726) Streamline getting started experience

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173965#comment-17173965
 ] 

Marcus Eagan commented on SOLR-14726:
-

I also think a video from someone in the community should be made. Some people 
learn differently. 

> Streamline getting started experience
> -
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: newdev
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our 
> best practices, that should also be followed in production. I have following 
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page 
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should 
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation 
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that 
> it can be easily executed from Google Colaboratory. Here's an example: 
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial 
> can be executed from those tools. Except for starting Solr, all other steps 
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.), 
> configsets from Solr's distribution (instead let the examples refer to them 
> from github)
> # Remove the post tool from Solr, curl should suffice.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14726) Streamline getting started experience

[Marcus Eagan (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eagan updated SOLR-14726:

Labels: newdev  (was: )

> Streamline getting started experience
> -
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: newdev
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our 
> best practices, that should also be followed in production. I have following 
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page 
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should 
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation 
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that 
> it can be easily executed from Google Colaboratory. Here's an example: 
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial 
> can be executed from those tools. Except for starting Solr, all other steps 
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.), 
> configsets from Solr's distribution (instead let the examples refer to them 
> from github)
> # Remove the post tool from Solr, curl should suffice.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13438) DELETE collection should remove AUTOCREATED configsets

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173962#comment-17173962
 ] 

Marcus Eagan commented on SOLR-13438:
-

[~ichattopadhyaya] I'll leave this issue open for a new dev to step in and get 
involved. If it is not fixed after a while, I will wrap it up. I personally 
have seen this issue cause many problems.

> DELETE collection should remove AUTOCREATED configsets
> --
>
> Key: SOLR-13438
> URL: https://issues.apache.org/jira/browse/SOLR-13438
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: newdev
>
> Current user experience:
> # User creates a collection (without specifying configset), and makes some 
> schema/config changes.
> # He's/She's not happy with how the changes turned out, so he/she deletes and 
> re-creates the collection.
> # He/she observes that the previously made settings changes persist. If 
> he/she is only aware of Schema and Config APIs and not explicitly aware of 
> the concept of configsets, this will be un-intuitive for him/her.
> Proposed:
> DELETE collection should delete the configset if it has the prefix 
> ".AUTOCREATED" and that configset isn't being shared by any other collection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13438) DELETE collection should remove AUTOCREATED configsets

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173668#comment-17173668
 ] 

Marcus Eagan commented on SOLR-13438:
-

[~ichattopadhyaya] It's a constant issue for many users. 

> DELETE collection should remove AUTOCREATED configsets
> --
>
> Key: SOLR-13438
> URL: https://issues.apache.org/jira/browse/SOLR-13438
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: newdev
>
> Current user experience:
> # User creates a collection (without specifying configset), and makes some 
> schema/config changes.
> # He's/She's not happy with how the changes turned out, so he/she deletes and 
> re-creates the collection.
> # He/she observes that the previously made settings changes persist. If 
> he/she is only aware of Schema and Config APIs and not explicitly aware of 
> the concept of configsets, this will be un-intuitive for him/her.
> Proposed:
> DELETE collection should delete the configset if it has the prefix 
> ".AUTOCREATED" and that configset isn't being shared by any other collection.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173490#comment-17173490
 ] 

Marcus Eagan commented on SOLR-14708:
-

I was able to query both nodes, but maybe my UI had some other issue. The
caching issue depends on the configset, it seems. I suppose the solution
will work sufficiently for the needs of the project and users will need to
adjust accordingly.

I'd rather you take this issue forward with input from others rather than
me  please.

On Fri, Aug 7, 2020 at 2:19 PM Tomas Eduardo Fernandez Lobbe (Jira) <



> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
> that we remove master/slave terminology from the Solr codebase. Now that's 
> complete, we need to ensure it is backward compatible to support rolling 
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
> upgrade Solr. 
> Tomas offered a helpful path in a now abandoned PR: 
> {quote}One way to get back compatibility and rolling upgrades could be to 
> make 9.x code be able to read previous formats, but write new format, and 
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a 
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x 
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept 
> parameter values for the legacy verbiage, or leader/follower, but only write 
> leader/follower. We need to then make 8_x work in the inverse way. The burden 
> here is not on that proposal or on the code in my view. Instead, the burden 
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three 
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and 
> the leader node is forced to fail and then is brought back.
> Case C: 
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a 
> rolling upgrade and a follower needs to become leader. 
> I know haven't listed all possible scenarios or everything that could happen. 
> Please let me know if you have thoughts or guidance on how best to accomplish 
> this work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173195#comment-17173195
 ] 

Marcus Eagan commented on SOLR-14708:
-

Also, even with this change aside, Solr 9 is very far from back compatibility 
in other areas.

> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
> that we remove master/slave terminology from the Solr codebase. Now that's 
> complete, we need to ensure it is backward compatible to support rolling 
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
> upgrade Solr. 
> Tomas offered a helpful path in a now abandoned PR: 
> {quote}One way to get back compatibility and rolling upgrades could be to 
> make 9.x code be able to read previous formats, but write new format, and 
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a 
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x 
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept 
> parameter values for the legacy verbiage, or leader/follower, but only write 
> leader/follower. We need to then make 8_x work in the inverse way. The burden 
> here is not on that proposal or on the code in my view. Instead, the burden 
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three 
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and 
> the leader node is forced to fail and then is brought back.
> Case C: 
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a 
> rolling upgrade and a follower needs to become leader. 
> I know haven't listed all possible scenarios or everything that could happen. 
> Please let me know if you have thoughts or guidance on how best to accomplish 
> this work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173011#comment-17173011
 ] 

Marcus Eagan edited comment on SOLR-14708 at 8/7/20, 2:54 PM:
--

Honestly [~tflobbe] there seems to be a lot of dependencies and other issues 
that challenge it. I will have to review in more closely with dedicated next 
week. 

Backward compatibility touches various parts of the application and will 
require a coordinated effort probably from you, AB, and may others. FastLRU 
Cache seems to exist in 8.6 still. This causes problems for replication in the 
tests.


was (Author: marcussorealheis):
Honestly [~tflobbe] there seems to be a lot of dependencies and other issues 
that challenge it. I will have to review in more closely with dedicated next 
week. 

Backward compatibility touches various parts of the application and will 
require a coordinated effort probably from you, AB, and may others.

> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
> that we remove master/slave terminology from the Solr codebase. Now that's 
> complete, we need to ensure it is backward compatible to support rolling 
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
> upgrade Solr. 
> Tomas offered a helpful path in a now abandoned PR: 
> {quote}One way to get back compatibility and rolling upgrades could be to 
> make 9.x code be able to read previous formats, but write new format, and 
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a 
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x 
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept 
> parameter values for the legacy verbiage, or leader/follower, but only write 
> leader/follower. We need to then make 8_x work in the inverse way. The burden 
> here is not on that proposal or on the code in my view. Instead, the burden 
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three 
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and 
> the leader node is forced to fail and then is brought back.
> Case C: 
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a 
> rolling upgrade and a follower needs to become leader. 
> I know haven't listed all possible scenarios or everything that could happen. 
> Please let me know if you have thoughts or guidance on how best to accomplish 
> this work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173011#comment-17173011
 ] 

Marcus Eagan commented on SOLR-14708:
-

Honestly [~tflobbe] there seems to be a lot of dependencies and other issues 
that challenge it. I will have to review in more closely with dedicated next 
week. 

Backward compatibility touches various parts of the application and will 
require a coordinated effort probably from you, AB, and may others.

> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
> that we remove master/slave terminology from the Solr codebase. Now that's 
> complete, we need to ensure it is backward compatible to support rolling 
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
> upgrade Solr. 
> Tomas offered a helpful path in a now abandoned PR: 
> {quote}One way to get back compatibility and rolling upgrades could be to 
> make 9.x code be able to read previous formats, but write new format, and 
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a 
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x 
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept 
> parameter values for the legacy verbiage, or leader/follower, but only write 
> leader/follower. We need to then make 8_x work in the inverse way. The burden 
> here is not on that proposal or on the code in my view. Instead, the burden 
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three 
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and 
> the leader node is forced to fail and then is brought back.
> Case C: 
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a 
> rolling upgrade and a follower needs to become leader. 
> I know haven't listed all possible scenarios or everything that could happen. 
> Please let me know if you have thoughts or guidance on how best to accomplish 
> this work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172952#comment-17172952
 ] 

Marcus Eagan commented on SOLR-14708:
-

There is also a very strong chance that I am not doing this right because it 
looks like some things have changed since I last ran a cluster in standalone 
mode.

> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
> that we remove master/slave terminology from the Solr codebase. Now that's 
> complete, we need to ensure it is backward compatible to support rolling 
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
> upgrade Solr. 
> Tomas offered a helpful path in a now abandoned PR: 
> {quote}One way to get back compatibility and rolling upgrades could be to 
> make 9.x code be able to read previous formats, but write new format, and 
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a 
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x 
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept 
> parameter values for the legacy verbiage, or leader/follower, but only write 
> leader/follower. We need to then make 8_x work in the inverse way. The burden 
> here is not on that proposal or on the code in my view. Instead, the burden 
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three 
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and 
> the leader node is forced to fail and then is brought back.
> Case C: 
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a 
> rolling upgrade and a follower needs to become leader. 
> I know haven't listed all possible scenarios or everything that could happen. 
> Please let me know if you have thoughts or guidance on how best to accomplish 
> this work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172947#comment-17172947
 ] 

Marcus Eagan edited comment on SOLR-14708 at 8/7/20, 7:18 AM:
--

Also, master/slave is not very documented as well. It is straightforward, but 
annoying to work with, for sure because there is little documentation.


was (Author: marcussorealheis):
Also, master/slave is not very documented as well. It is straightforward, but 
annoying to work with, for sure.

> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
> that we remove master/slave terminology from the Solr codebase. Now that's 
> complete, we need to ensure it is backward compatible to support rolling 
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
> upgrade Solr. 
> Tomas offered a helpful path in a now abandoned PR: 
> {quote}One way to get back compatibility and rolling upgrades could be to 
> make 9.x code be able to read previous formats, but write new format, and 
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a 
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x 
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept 
> parameter values for the legacy verbiage, or leader/follower, but only write 
> leader/follower. We need to then make 8_x work in the inverse way. The burden 
> here is not on that proposal or on the code in my view. Instead, the burden 
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three 
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and 
> the leader node is forced to fail and then is brought back.
> Case C: 
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a 
> rolling upgrade and a follower needs to become leader. 
> I know haven't listed all possible scenarios or everything that could happen. 
> Please let me know if you have thoughts or guidance on how best to accomplish 
> this work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172947#comment-17172947
 ] 

Marcus Eagan commented on SOLR-14708:
-

Also, master/slave is not very documented as well. It is straightforward, but 
annoying to work with, for sure.

> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
> that we remove master/slave terminology from the Solr codebase. Now that's 
> complete, we need to ensure it is backward compatible to support rolling 
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
> upgrade Solr. 
> Tomas offered a helpful path in a now abandoned PR: 
> {quote}One way to get back compatibility and rolling upgrades could be to 
> make 9.x code be able to read previous formats, but write new format, and 
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a 
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x 
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept 
> parameter values for the legacy verbiage, or leader/follower, but only write 
> leader/follower. We need to then make 8_x work in the inverse way. The burden 
> here is not on that proposal or on the code in my view. Instead, the burden 
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three 
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and 
> the leader node is forced to fail and then is brought back.
> Case C: 
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a 
> rolling upgrade and a follower needs to become leader. 
> I know haven't listed all possible scenarios or everything that could happen. 
> Please let me know if you have thoughts or guidance on how best to accomplish 
> this work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172946#comment-17172946
 ] 

Marcus Eagan commented on SOLR-14708:
-

so far, [~tflobbe] test Case A fails in a few ways:

Replication is not working properly.
Recovery did not happen appropriately.
Admin UI doesn't work either. There is more work to do on the back-compat front.

> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
> that we remove master/slave terminology from the Solr codebase. Now that's 
> complete, we need to ensure it is backward compatible to support rolling 
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
> upgrade Solr. 
> Tomas offered a helpful path in a now abandoned PR: 
> {quote}One way to get back compatibility and rolling upgrades could be to 
> make 9.x code be able to read previous formats, but write new format, and 
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a 
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x 
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept 
> parameter values for the legacy verbiage, or leader/follower, but only write 
> leader/follower. We need to then make 8_x work in the inverse way. The burden 
> here is not on that proposal or on the code in my view. Instead, the burden 
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three 
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and 
> the leader node is forced to fail and then is brought back.
> Case C: 
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a 
> rolling upgrade and a follower needs to become leader. 
> I know haven't listed all possible scenarios or everything that could happen. 
> Please let me know if you have thoughts or guidance on how best to accomplish 
> this work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8626) standardise test class naming

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172712#comment-17172712
 ] 

Marcus Eagan commented on LUCENE-8626:
--

There are many many areas where I am looking to improve the developer 
experience and the code hygiene. I'm not some guru of clean code or anything, 
but I am starting go through my laundry list of things that drive me (and 
others) nuts and reduces the overall quality of the project. 

I intend to add a pre-commit check to enforce this and other standards as they 
come through.

> standardise test class naming
> -
>
> Key: LUCENE-8626
> URL: https://issues.apache.org/jira/browse/LUCENE-8626
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Priority: Major
> Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, 
> SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch
>
>
> This was mentioned and proposed on the dev mailing list. Starting this ticket 
> here to start to make it happen?
> History: This ticket was created as 
> https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got 
> JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8626) standardise test class naming

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172709#comment-17172709
 ] 

Marcus Eagan commented on LUCENE-8626:
--

[~cpoerschke] Thank you very much for kicking this effort off back in 2018. 
This issue has many implications for problems. And for what I am working on, 
there is a detriment to my productivity because of it. I'm sure I am not alone. 

If you don't mind, I'd like to take this effort a bit further and to completion 
via a PR. 

> standardise test class naming
> -
>
> Key: LUCENE-8626
> URL: https://issues.apache.org/jira/browse/LUCENE-8626
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Priority: Major
> Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, 
> SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch
>
>
> This was mentioned and proposed on the dev mailing list. Starting this ticket 
> here to start to make it happen?
> History: This ticket was created as 
> https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got 
> JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17171755#comment-17171755
 ] 

Marcus Eagan commented on SOLR-14702:
-

Makes sense to me.

Sent via Superhuman iOS ( https://sprh.mn/?vip=m...@marcuseagan.com )




> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 13h 40m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169479#comment-17169479
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/4/20, 5:40 PM:
--

[~o...@apache.org] and [~simonwillnauer] agree, at least, on Twitter: 
[https://twitter.com/otisg/status/127361291415937]

 

Well, I know they both agree. They're both reasonable and kind.


was (Author: marcussorealheis):
[~o...@apache.org] and [~simonwillnauer] agree, ate least, on Twitter: 
[https://twitter.com/otisg/status/127361291415937]

 

Well, I know they both agree. They're both reasonable and kind.

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 12h 40m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eagan updated SOLR-14708:

Description: 
In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
that we remove master/slave terminology from the Solr codebase. Now that's 
complete, we need to ensure it is backward compatible to support rolling 
upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
upgrade Solr. 

Tomas offered a helpful path in a now abandoned PR: 
{quote}One way to get back compatibility and rolling upgrades could be to make 
9.x code be able to read previous formats, but write new format, and make 8.x 
(since 8.7) read new and old, but write old? Anyone wanting to do a rolling 
upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 8.7 would 
still work.
All the code other than the requests/responses could be changed in 8_x branch, 
in addition to master.
{quote}
The approach that we will take is to add a ternary operator in 9_X to accept 
parameter values for the legacy verbiage, or leader/follower, but only write 
leader/follower. We need to then make 8_x work in the inverse way. The burden 
here is not on that proposal or on the code in my view. Instead, the burden is 
on the test plan.

If anyone has any guidance please share but here are my thoughts:

Case A:

Test the case where a user is running a standalone cluster in 8 with three 
nodes but then updates one of the nodes.

Case B:

Test the case where a user is running a mixed cluster standalone cluster, and 
the leader node is forced to fail and then is brought back.

Case C: 

A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a rolling 
upgrade and a follower needs to become leader. 

I know haven't listed all possible scenarios or everything that could happen. 
Please let me know if you have thoughts or guidance on how best to accomplish 
this work.

> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>
> In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed 
> that we remove master/slave terminology from the Solr codebase. Now that's 
> complete, we need to ensure it is backward compatible to support rolling 
> upgrades from 8.7.x to 9.x because we really ought not to make it harder to 
> upgrade Solr. 
> Tomas offered a helpful path in a now abandoned PR: 
> {quote}One way to get back compatibility and rolling upgrades could be to 
> make 9.x code be able to read previous formats, but write new format, and 
> make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a 
> rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 
> 8.7 would still work.
> All the code other than the requests/responses could be changed in 8_x 
> branch, in addition to master.
> {quote}
> The approach that we will take is to add a ternary operator in 9_X to accept 
> parameter values for the legacy verbiage, or leader/follower, but only write 
> leader/follower. We need to then make 8_x work in the inverse way. The burden 
> here is not on that proposal or on the code in my view. Instead, the burden 
> is on the test plan.
> If anyone has any guidance please share but here are my thoughts:
> Case A:
> Test the case where a user is running a standalone cluster in 8 with three 
> nodes but then updates one of the nodes.
> Case B:
> Test the case where a user is running a mixed cluster standalone cluster, and 
> the leader node is forced to fail and then is brought back.
> Case C: 
> A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a 
> rolling upgrade and a follower needs to become leader. 
> I know haven't listed all possible scenarios or everything that could happen. 
> Please let me know if you have thoughts or guidance on how best to accomplish 
> this work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eagan updated SOLR-14708:

Environment: (was: In 
[SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed that 
we remove master/slave terminology from the Solr codebase. Now that's complete, 
we need to ensure it is backward compatible to support rolling upgrades from 
8.7.x to 9.x because we really ought not to make it harder to upgrade Solr. 

Tomas offered a helpful path in a now abandoned PR: 
{quote}One way to get back compatibility and rolling upgrades could be to make 
9.x code be able to read previous formats, but write new format, and make 8.x 
(since 8.7) read new and old, but write old? Anyone wanting to do a rolling 
upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 8.7 would 
still work.
All the code other than the requests/responses could be changed in 8_x branch, 
in addition to master.
{quote}
The approach that we will take is to add a ternary operator in 9_X to accept 
parameter values for the legacy verbiage, or leader/follower, but only write 
leader/follower. We need to then make 8_x work in the inverse way. The burden 
here is not on that proposal or on the code in my view. Instead, the burden is 
on the test plan.

If anyone has any guidance please share but here are my thoughts:

Case A:

Test the case where a user is running a standalone cluster in 8 with three 
nodes but then updates one of the nodes.

Case B:

Test the case where a user is running a mixed cluster standalone cluster, and 
the leader node is forced to fail and then is brought back.

Case C: 

A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a rolling 
upgrade and a follower needs to become leader. 

I know haven't listed all possible scenarios or everything that could happen. 
Please let me know if you have thoughts or guidance on how best to accomplish 
this work.)

> Backward-Compatible Replication
> ---
>
> Key: SOLR-14708
> URL: https://issues.apache.org/jira/browse/SOLR-14708
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Marcus Eagan
>Priority: Critical
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14708) Backward-Compatible Replication

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14708:
---

 Summary: Backward-Compatible Replication
 Key: SOLR-14708
 URL: https://issues.apache.org/jira/browse/SOLR-14708
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
 Environment: In 
[SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed that 
we remove master/slave terminology from the Solr codebase. Now that's complete, 
we need to ensure it is backward compatible to support rolling upgrades from 
8.7.x to 9.x because we really ought not to make it harder to upgrade Solr. 

Tomas offered a helpful path in a now abandoned PR: 
{quote}One way to get back compatibility and rolling upgrades could be to make 
9.x code be able to read previous formats, but write new format, and make 8.x 
(since 8.7) read new and old, but write old? Anyone wanting to do a rolling 
upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 8.7 would 
still work.
All the code other than the requests/responses could be changed in 8_x branch, 
in addition to master.
{quote}
The approach that we will take is to add a ternary operator in 9_X to accept 
parameter values for the legacy verbiage, or leader/follower, but only write 
leader/follower. We need to then make 8_x work in the inverse way. The burden 
here is not on that proposal or on the code in my view. Instead, the burden is 
on the test plan.

If anyone has any guidance please share but here are my thoughts:

Case A:

Test the case where a user is running a standalone cluster in 8 with three 
nodes but then updates one of the nodes.

Case B:

Test the case where a user is running a mixed cluster standalone cluster, and 
the leader node is forced to fail and then is brought back.

Case C: 

A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a rolling 
upgrade and a follower needs to become leader. 

I know haven't listed all possible scenarios or everything that could happen. 
Please let me know if you have thoughts or guidance on how best to accomplish 
this work.
Reporter: Marcus Eagan






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170621#comment-17170621
 ] 

Marcus Eagan commented on SOLR-14702:
-

This was not addressed here in the Jira but Tomas raised a really important 
point in the PR. I'm revisiting my initial PR (leader/follower) and finishing 
up for the first phase. I think the second phase should be backward 
compatibility. The third phase should be the build pipeline tools. I don't know 
how urgent it should be.

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 11h
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170569#comment-17170569
 ] 

Marcus Eagan commented on SOLR-14702:
-

{quote}I think this is really off? Definitely alerts will be different. As we 
both agreed, the architectures are different and so are the things to 
monitor/alert on. This is no different than having Solr in SolrCloud mode 
running in completely different infrastructure (say, Kubernetes vs bare metal), 
the alerts and actions to take are different. If you have enough clusters to 
need a "reminder" of the mode they are in running on you most likely have a 
tool to track it.
{quote}
My point was that people will take logical shortcuts to comprehend, looking for 
keywords and deductions. SolrCloud on Kubernetes vs bare metal is 
non-analagous, especially considering you can run Kubernetes on bare metal. 
Kubernetes is just server orchestration software. You can put it on EC2, 
baremetal, or wherever you can find 4 GB of RAM and 2 CPUs. 

Regardless of the tracking/alerting tool, the output of it should be as obvious 
as possible. Context switching with conflicting terms is a recipe for 
production outages.

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 7h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170566#comment-17170566
 ] 

Marcus Eagan commented on SOLR-14702:
-

{quote}ReplicationHandler/IndexFetcher code continuously log including "master" 
and "slave" that, in the context of both recoveries and replication for 
TLOG/PULL replicas, actually refer to leaders and followers.
{quote}
Can you clarify? I think you are missing a word or clause here. I don't 
understand what you are saying.

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 7h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Issue Comment Deleted] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eagan updated SOLR-14702:

Comment: was deleted

(was: {quote}Also, Is the secondary second to what? is there some order of 
things? If there is a repeater, the "secondary" is not actually the second to 
get the index.
{quote}
Come again?)

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 7h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170565#comment-17170565
 ] 

Marcus Eagan commented on SOLR-14702:
-

{quote}Also, Is the secondary second to what? is there some order of things? If 
there is a repeater, the "secondary" is not actually the second to get the 
index.
{quote}
Come again?

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 7h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170546#comment-17170546
 ] 

Marcus Eagan commented on SOLR-14702:
-

Btw, thanks for being so engaged in the ticket and driving it toward 
resolution. All constructive feedback is welcome, especially substantive 
feedback that supports a swift and robust resolution for the community. Very 
much appreciated. Usability is my top priority. 

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 7h 40m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170544#comment-17170544
 ] 

Marcus Eagan commented on SOLR-14702:
-

Ahhh. Thanks for the clarification. So, yeah. I guess you are in effect arguing 
in favor of Pager Duty alerts that read (for illustrative and rhetorical 
pruposes):

Hey, legacy leader went down in Leibniz cluster.

As opposed to -

Hey, the primary node went down in the Ramanujan cluster.

It's very clear in the second example which architecture was impacted and what 
action needs to be taken. In the Leibniz cluster are we talking about the 
master/slave legacy architecture or are we talking about the leader/follower 
implementation that came first as is the case of SolrCloud?

I understand you but I disagree with you. Are you willing to do the work to get 
the leader/follower branch up to back-compat? 

 

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 7h 40m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170533#comment-17170533
 ] 

Marcus Eagan commented on SOLR-14702:
-

{quote}Also, Is the secondary second to what? is there some order of things? If 
there is a repeater, the "secondary" is not actually the second to get the 
index.
{quote}
If there is a repeater it functions like both a secondary and primary. I 
included that in the PR. Do you have any more thoughts on what needs to change 
in the code beyond the name, to support backward compatibility? I'm really 
interested in that stuff because I have to do that at some point regardless of 
what the name is, ultimately. 

I also would like a firm commitment from the community on how we ensure that 
this doesn't linger beyond the initial version. I don't want to see 
master/slave ever again and I think others, some of whom I tried to recruit for 
the project, would like to see it either. 

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170528#comment-17170528
 ] 

Marcus Eagan commented on SOLR-14702:
-

Tomas,

 
{quote}because I have demonstrated the architectures are different

I don't think that was ever in doubt?
{quote}
These were your words a few hours ago brother: 
{quote}it's the same in both architecture IMO
{quote}
It's not the same architecture so glad we agree on it. I think because the 
support models are significant different, two different names could actually be 
beneficial as Shawn Heisey alluded to, especially for independent consultants 
like working with multiple Solr footprints of different versions and 
replication modes. 

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170475#comment-17170475
 ] 

Marcus Eagan commented on SOLR-14702:
-

[~erickerickson]Thanks for the help. The masterURL reference should be removed 
in the latest state of the master but I did not catch the secondary typo in the 
config. I looked and didn't see it. Thanks for helping out here. Pushing up the 
change.

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170473#comment-17170473
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/4/20, 12:00 AM:
---

[~tflobbe] I view almost any comment that detracts from the goal of getting 
master/slave out of the codebase to a distraction from that which is imperative 
and of the utmost importance. If you have a really compelling reason other than 
you like it because I have demonstrated the architectures are different then I 
think you should drop it.


was (Author: marcussorealheis):
[~tflobbe] I view almost any comment that detracts from the goal of getting 
master/slave out of the codebase to a distraction from that which is imperative 
and of the utmost importance. If you have a really compelling reason other than 
you like it because I have demonstrated the architectures are different than I 
think you should drop it.

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170474#comment-17170474
 ] 

Marcus Eagan commented on SOLR-14702:
-

bq. We already have a difficult time getting users to understand the 
complexities involved, particularly because SolrCloud actually does utilize 
replication, in a way that's quite different than legacy.  If we use the same 
terms for the different things found in the two different modes, that confusion 
is going to get worse.

+1

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170473#comment-17170473
 ] 

Marcus Eagan commented on SOLR-14702:
-

[~tflobbe] I view almost any comment that detracts from the goal of getting 
master/slave out of the codebase to a distraction from that which is imperative 
and of the utmost importance. If you have a really compelling reason other than 
you like it because I have demonstrated the architectures are different than I 
think you should drop it.

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
> Attachments: SOLR-14742-testfix.patch
>
>  Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170466#comment-17170466
 ] 

Marcus Eagan commented on SOLR-14702:
-

Again, I don't care I just want the words removed and curious about
 the technical basis for your objection. 

In non-SolrCloud, there is no indexing at all when the primary node goes down.

In SolrCloud, a follower can emerge as the leader without human intervention.

Those are different architectures in simple terms.





> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170458#comment-17170458
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 11:17 PM:
---

hey guys, I opened a PR for both but the longer we delay on merging the more 
trouble it will be to get it in. So I will update the leader/follower one (the 
first one actually) that fell behind a bit and didn't get as much love, but 
please don't hesitate to continue to work on whichever of the two PRs you 
prefer because I'm frankly sick of reading the words master and slave. It's 
really stressful. 

And [~tflobbe] I think your analysis sheds light on the fact that 
leader/follower is not what's happening in non-SolrCloud mode. Replicas are not 
replicas of a leader. They are replicas. If the "leader" fails the state of the 
cluster is very different for an end-user managing the cluster compared to when 
a leader goes down in SolrCloud. They are very different.

This is an aside: Can I ask why you support colliding terms for reasons other 
than you "personally like to use 'leader/follower?'"

As I said, I really don't care. I just want it to leave the code base so I 
never have to see it again, same with others who don't like to think about it.


was (Author: marcussorealheis):
hey guys, I opened a PR for both but the longer we delay on merging the more 
trouble it will be to get it in. So I will keep update the leader/follower one 
that fell behind a bit and didn't get as much love, but please don't hesitate 
to continue to work on whichever of the two PRs you prefer because I'm frankly 
sick of reading the words master and slave. It's really stressful. 

And [~tflobbe] I think your analysis sheds light on the fact that 
leader/follower is not what's happening in non-SolrCloud mode. Replicas are not 
replicas of a leader. They are replicas. If the "leader" fails the state of the 
cluster is very different for an end-user managing the cluster compared to when 
a leader goes down in SolrCloud. They are very different.

Can I ask why you support colliding terms for reasons other than you 
"personally like to use 'leader/follower?'"



> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170458#comment-17170458
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 11:14 PM:
---

hey guys, I opened a PR for both but the longer we delay on merging the more 
trouble it will be to get it in. So I will keep update the leader/follower one 
that fell behind a bit and didn't get as much love, but please don't hesitate 
to continue to work on whichever of the two PRs you prefer because I'm frankly 
sick of reading the words master and slave. It's really stressful. 

And [~tflobbe] I think your analysis sheds light on the fact that 
leader/follower is not what's happening in non-SolrCloud mode. Replicas are not 
replicas of a leader. They are replicas. If the "leader" fails the state of the 
cluster is very different for an end-user managing the cluster compared to when 
a leader goes down in SolrCloud. They are very different.

Can I ask why you support colliding terms for reasons other than you 
"personally like to use 'leader/follower?'"




was (Author: marcussorealheis):
hey guys, I opened a PR for both but the longer we delay on merging the more 
trouble it will be to get it in. So I will keep update the leader/follower one 
that fell behind a bit and didn't get as much love, but please don't hesitate 
to continue to work on whichever of the two PRs you prefer because I'm frankly 
sick of reading the words master and slave. It's really stressful. 

And [~tflobbe] I think your analysis sheds light on the fact that 
leader/follower is not what's happening in non-SolrCloud mode. Replicas are 
replicas of a leader. They are replicas. If the "leader" fails the state of the 
cluster is very different for an end-user managing the cluster compared to when 
a leader goes down in SolrCloud. They are very different.

Can I ask why you support colliding terms for reasons other than you 
"personally like to use 'leader/follower?'"



> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170458#comment-17170458
 ] 

Marcus Eagan commented on SOLR-14702:
-

hey guys, I opened a PR for both but the longer we delay on merging the more 
trouble it will be to get it in. So I will keep update the leader/follower one 
that fell behind a bit and didn't get as much love, but please don't hesitate 
to continue to work on whichever of the two PRs you prefer because I'm frankly 
sick of reading the words master and slave. It's really stressful. 

And [~tflobbe] I think your analysis sheds light on the fact that 
leader/follower is not what's happening in non-SolrCloud mode. Replicas are 
replicas of a leader. They are replicas. If the "leader" the state of the 
cluster is very different for an end-user managing the cluster compared to when 
a leader goes down in SolrCloud. They are very different.

Can I ask why you support colliding terms for reasons other than you 
"personally like to use 'leader/follower?'"



> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170458#comment-17170458
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 11:12 PM:
---

hey guys, I opened a PR for both but the longer we delay on merging the more 
trouble it will be to get it in. So I will keep update the leader/follower one 
that fell behind a bit and didn't get as much love, but please don't hesitate 
to continue to work on whichever of the two PRs you prefer because I'm frankly 
sick of reading the words master and slave. It's really stressful. 

And [~tflobbe] I think your analysis sheds light on the fact that 
leader/follower is not what's happening in non-SolrCloud mode. Replicas are 
replicas of a leader. They are replicas. If the "leader" fails the state of the 
cluster is very different for an end-user managing the cluster compared to when 
a leader goes down in SolrCloud. They are very different.

Can I ask why you support colliding terms for reasons other than you 
"personally like to use 'leader/follower?'"




was (Author: marcussorealheis):
hey guys, I opened a PR for both but the longer we delay on merging the more 
trouble it will be to get it in. So I will keep update the leader/follower one 
that fell behind a bit and didn't get as much love, but please don't hesitate 
to continue to work on whichever of the two PRs you prefer because I'm frankly 
sick of reading the words master and slave. It's really stressful. 

And [~tflobbe] I think your analysis sheds light on the fact that 
leader/follower is not what's happening in non-SolrCloud mode. Replicas are 
replicas of a leader. They are replicas. If the "leader" the state of the 
cluster is very different for an end-user managing the cluster compared to when 
a leader goes down in SolrCloud. They are very different.

Can I ask why you support colliding terms for reasons other than you 
"personally like to use 'leader/follower?'"



> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170383#comment-17170383
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 7:44 PM:
--

[~erickerickson] these are the tests:
 org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication
org.apache.solr.handler.TestReplicationHandler.doTestRepeater 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl


was (Author: marcussorealheis):
[~erickerickson] these are the tests:
 {{org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication
org.apache.solr.handler.TestReplicationHandler.doTestRepeater 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl}}

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h 20m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170383#comment-17170383
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 7:44 PM:
--

[~erickerickson] these are the tests:
 {{org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication
org.apache.solr.handler.TestReplicationHandler.doTestRepeater 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl}}


was (Author: marcussorealheis):
[~erickerickson] these are the tests:
 org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}}
 {{org.apache.solr.handler.TestReplicationHandler.doTestRepeater 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h 20m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170383#comment-17170383
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 7:43 PM:
--

[~erickerickson] these are the tests:
 org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}}
 {{org.apache.solr.handler.TestReplicationHandler.doTestRepeater 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl


was (Author: marcussorealheis):
[~erickerickson] these are the tests:
 {
{{{org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}}
{{org.apache.solr.handler.TestReplicationHandler.doTestRepeater 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h 20m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170383#comment-17170383
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 7:43 PM:
--

[~erickerickson] these are the tests:
 {
{{{org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}}
{{org.apache.solr.handler.TestReplicationHandler.doTestRepeater 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl


was (Author: marcussorealheis):
[~erickerickson] these are the tests:

org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}} 
}}
org.apache.solr.handler.TestReplicationHandler.doTestRepeater 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h 20m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170383#comment-17170383
 ] 

Marcus Eagan commented on SOLR-14702:
-

[~erickerickson] these are the tests:

org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}} 
}}
org.apache.solr.handler.TestReplicationHandler.doTestRepeater 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h 20m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170143#comment-17170143
 ] 

Marcus Eagan commented on SOLR-14702:
-

[~janhoy] see this if you haven't: 
[https://tools.ietf.org/id/draft-knodel-terminology-00.html]

Lots of work to do in the Solr and Lucene repos 

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170124#comment-17170124
 ] 

Marcus Eagan commented on SOLR-14702:
-

{quote}I think we all appreciate Marcus vulunteering to help with the work. But 
since he was probably not ware of [~anshum]'s great contribution towards 
tackling this, by involving the entire user community on the dev list, I wanted 
to shed light on the existence of the existing discussion. Once that discussion 
converges, either through consensus or vote, then we can continue discussion on 
the implementation here and in the PR. If something else than primary/secondary 
is chosen, then it should be fairly quick to update the patch.
{quote}
Hi [~janhoy] Thank you for making me aware of the discussion. I did not see it 
and wasn't made aware of it. I complained about this nomenclature as early of 
March of last year when I was still at Lucidworks. It received no traction or 
bias toward action then, so I took it upon myself to rip it out because over 
the past few weeks I have had the discomfort of focusing a lot more on the open 
source and had to read it over and over. It drives me mad. I will check out the 
discussion and share what I have already done. Since there is so much code in 
so many places, the effort was non-trivial purely because of volume, but I have 
done it 100% for primary/secondary, and 80% for leader/follower. Let me paste 
my PR into the user list. Just re-visiting and reviewing the PR gets me riled 
up so I hope we can find swift resolution on something that happened months 
ago. Some database technologies created at the same time as Solr never heavily 
used such nomenclature officially so I'm hopeful for a switft corrective 
action. 

 

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 6h
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14705) Release Smoke Test Script Shows Unusable JDK Version

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14705:
---

 Summary: Release Smoke Test Script Shows Unusable JDK Version
 Key: SOLR-14705
 URL: https://issues.apache.org/jira/browse/SOLR-14705
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: release-scripts
Affects Versions: master (9.0)
Reporter: Marcus Eagan


The script works fine, but the help text in the smoke test script needs to be 
replaced. Should be Java 8 for now and moved to Java 11 when the community is 
preparing to release Solr 9. :)

Here's the output:


usage: smokeTestRelease.py [-h] [--tmp-dir PATH] [--not-signed]
   [--local-keys PATH] [--revision REVISION]
   [--version X.Y.Z(-ALPHA|-BETA)?]
   [--test-java9 JAVA9_HOME] [--download-only]
   url ...
 

I wouldn't touch Java 9 with a ten foot pole, and nor should new releases.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169679#comment-17169679
 ] 

Marcus Eagan commented on SOLR-14702:
-

>I suggest we stick to one naming convention. leader follower (for both 
>standalone and cluster modes)

I think it is confusing. People won't know which is which, and one goes away, 
people will be less empowered and clueless. I think running with 
primary/secondary for the legacy system is good because it lets people know 
that they are using the standalone mode. I suspect that it could one day go 
away...although I know there are many in the community that think otherwise.

Whatever happens in the future, leader/follower refers to a different mechanism 
and something architecturally different than what's happening in standalone 
mode, hence the different names. They need to be tuned different, scaled 
differently, and managed differently. 

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14701) Deprecate Schemaless Mode (Discussion)

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169654#comment-17169654
 ] 

Marcus Eagan commented on SOLR-14701:
-

>Even though dev@ list may have been a better place

[~ichattopadhyaya] I like to discuss things on the mailing list, but it seems 
efforts that are in the mailing list mostly result in mostly talk and little 
action. They do serve to preserve context very well but not much of a forcing 
function. I think most are flippant about email because it is so polluted in 
many cases.

[~erickerickson] Great suggestion. We should implement it.

 

 

> Deprecate Schemaless Mode (Discussion)
> --
>
> Key: SOLR-14701
> URL: https://issues.apache.org/jira/browse/SOLR-14701
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Marcus Eagan
>Priority: Major
>
> I know this won't be the most popular ticket out there, but I am growing more 
> and more sympathetic to the idea that we should rip many of the freedoms out 
> that cause users more harm than not. One of the freedoms I saw time and time 
> again to cause issues was schemaless mode. It doesn't work as named or 
> documented, so I think it should be deprecated. 
> If you use it in production reliably and in a way that cannot be accomplished 
> another way, I am happy to hear from more knowledgeable folks as to why 
> deprecation is a bad idea. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169649#comment-17169649
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/2/20, 10:26 PM:
---

For the repo, I think trunk would be fine, but I think that we should limit the 
scope for the first overhaul. The second one to remove such language can target 
the branch names and the build systems, for instance, or simply be included as 
a part of Mark's work. Non-voting contributor so leaving the concrete decisions 
to the committers. :)


was (Author: marcussorealheis):
For the repo, I think trunk would be fine, but I think that we should limit the 
scope for the first overhaul. The second one to remove such language can target 
the branch names and the build systems, for instance. Non-voting contributor so 
leaving the concrete decisions to the committers. :)

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169649#comment-17169649
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/2/20, 10:25 PM:
---

For the repo, I think trunk would be fine, but I think that we should limit the 
scope for the first overhaul. The second one to remove such language can target 
the branch names and the build systems, for instance. Non-voting contributor so 
leaving the concrete decisions to the committers. :)


was (Author: marcussorealheis):
For the repo, I think trunk would be fine, but I think that we should limit the 
scope for the first overhaul. The second one to remove such language can target 
the branch names and the build systems, for instance.

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169649#comment-17169649
 ] 

Marcus Eagan commented on SOLR-14702:
-

For the repo, I think trunk would be fine, but I think that we should limit the 
scope for the first overhaul. The second one to remove such language can target 
the branch names and the build systems, for instance.

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169648#comment-17169648
 ] 

Marcus Eagan commented on SOLR-14702:
-

[~erickerickson] Thanks for the contribution, I like leader/follower as well. 
My first pull request incorporated the change. The reason I have chose 
primary/secondary is to vocabulary conflict with the leader/follower usage 
already in the code base. I guess there is not much overlap but it could still 
be confusing for some.

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eagan updated SOLR-14702:

Description: 
Every time I read _master_ and _slave_, I get pissed.

I think about the last and only time I remember visiting my maternal great 
grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
he lost his legs, and then he was back to being a sharecropper somehow after 
the war. Crazy, I know. I don't know if the world still called his job 
sharecropping in 1993, but he was basically a slave—in America. He lived in the 
same shack that his father, and his grandfather (born a slave) lived in down in 
Alabama. Believe it or not, my dad's (born in 1926) grandfather was actually 
born a slave, freed shortly after birth by his owner father. I never met him, 
though. He died in the 40s.

Anyway, I cannot police all terms in the repo and do not wish to. This 
master/slave shit is archaic and misleading on technical grounds. Thankfully, 
there's only a handful of files in code and documentation that still talk about 
masters and slaves. We should replace all of them.

There are so many ways to reword it. In fact, unless anyone else objects or 
wants to do the grunt work to help my stress levels, I will open the pull 
request myself in effort to make this project and community more inviting to 
people of all backgrounds and histories. We can have leader/follower, or 
primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
garbage. 

 

  was:
Every time I read _master_ and _slave_, I get pissed.

I think about the last and only time I remember visiting my maternal great 
grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
he lost his legs, and then he was back to being a sharecropper somehow after 
the war. Crazy, I know. I don't know if the world still called his job 
sharecropping in 1993, but he was basically a slave—in America. He lived in the 
same shack that his father, and his grandfather (born a slave) lived in down in 
Alabama. Believe it or not, my dad's (born in 1926) grandfather was actually 
born a slave, freed shortly after birth by his owner father. I never met him, 
though. He died in the 40s.

Anyway, I cannot police all terms in the repo and do not wish to. This 
master/slave shit is archaic and mis-leading on technical grounds. Thankfully, 
there's only a handful of files in code and documentation that still talk about 
masters and slaves. We should replace all of them.

There are so many ways to reword it. In fact, unless anyone else objects or 
wants to do the grunt work to help my stress levels, I will open the pull 
request myself in effort to make this project and community more inviting to 
people of all backgrounds and histories. We can have leader/follower, or 
primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
garbage. 

 


> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and misleading on technical grounds. Thankfully, 
> there's only a handful of files in code and documentation that still talk 
> about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eagan updated SOLR-14702:

Description: 
Every time I read _master_ and _slave_, I get pissed.

I think about the last and only time I remember visiting my maternal great 
grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
he lost his legs, and then he was back to being a sharecropper somehow after 
the war. Crazy, I know. I don't know if the world still called his job 
sharecropping in 1993, but he was basically a slave—in America. He lived in the 
same shack that his father, and his grandfather (born a slave) lived in down in 
Alabama. Believe it or not, my dad's (born in 1926) grandfather was actually 
born a slave, freed shortly after birth by his owner father. I never met him, 
though. He died in the 40s.

Anyway, I cannot police all terms in the repo and do not wish to. This 
master/slave shit is archaic and mis-leading on technical grounds. Thankfully, 
there's only a handful of files in code and documentation that still talk about 
masters and slaves. We should replace all of them.

There are so many ways to reword it. In fact, unless anyone else objects or 
wants to do the grunt work to help my stress levels, I will open the pull 
request myself in effort to make this project and community more inviting to 
people of all backgrounds and histories. We can have leader/follower, or 
primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
garbage. 

 

  was:
Every time I read _master_ and _slave_, I get pissed.

I think about the last and only time I remember visiting my maternal grandpa in 
Alabama at four years old. He was a sharecropper before WWI, where he lost his 
legs, and then he was back to being a sharecropper somehow after the war. 
Crazy, I know. I don't know if the world still called his job sharecropping in 
1993, but he was basically a slave—in America. He lived in the same shack that 
his father, and his grandfather (born a slave) lived in down in Alabama. 
Believe it or not, my dad's (born in 1926) grandfather was actually born a 
slave, freed shortly after birth by his owner father. I never met him, though. 
He died in the 40s.

Anyway, I cannot police all terms in the repo and do not wish to. This 
master/slave shit is archaic and mis-leading on technical grounds. Thankfully, 
there's only a handful of files in code and documentation that still talk about 
masters and slaves. We should replace all of them.

There are so many ways to reword it. In fact, unless anyone else objects or 
wants to do the grunt work to help my stress levels, I will open the pull 
request myself in effort to make this project and community more inviting to 
people of all backgrounds and histories. We can have leader/follower, or 
primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
garbage. 

_Community over code._

 


> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal great 
> grandpa in Alabama at four years old. He was a sharecropper before WWI, where 
> he lost his legs, and then he was back to being a sharecropper somehow after 
> the war. Crazy, I know. I don't know if the world still called his job 
> sharecropping in 1993, but he was basically a slave—in America. He lived in 
> the same shack that his father, and his grandfather (born a slave) lived in 
> down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was 
> actually born a slave, freed shortly after birth by his owner father. I never 
> met him, though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and mis-leading on technical grounds. 
> Thankfully, there's only a handful of files in code and documentation that 
> still talk about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira

[jira] [Updated] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eagan updated SOLR-14702:

Description: 
Every time I read _master_ and _slave_, I get pissed.

I think about the last and only time I remember visiting my maternal grandpa in 
Alabama at four years old. He was a sharecropper before WWI, where he lost his 
legs, and then he was back to being a sharecropper somehow after the war. 
Crazy, I know. I don't know if the world still called his job sharecropping in 
1993, but he was basically a slave—in America. He lived in the same shack that 
his father, and his grandfather (born a slave) lived in down in Alabama. 
Believe it or not, my dad's (born in 1926) grandfather was actually born a 
slave, freed shortly after birth by his owner father. I never met him, though. 
He died in the 40s.

Anyway, I cannot police all terms in the repo and do not wish to. This 
master/slave shit is archaic and mis-leading on technical grounds. Thankfully, 
there's only a handful of files in code and documentation that still talk about 
masters and slaves. We should replace all of them.

There are so many ways to reword it. In fact, unless anyone else objects or 
wants to do the grunt work to help my stress levels, I will open the pull 
request myself in effort to make this project and community more inviting to 
people of all backgrounds and histories. We can have leader/follower, or 
primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
garbage. 

_Community over code._

 

  was:
Every time I read _master_ and _slave_, I get pissed.

I think about the last and only time I remember visiting my maternal grandpa in 
Alabama at four years old. He was a sharecropper before WWI, where he lost his 
legs, and then he was back to being a sharecropper somehow after the war. 
Crazy, I know. I don't know if the world still called his job sharecropping in 
1993, but he was basically a slave—in America. He lived in the same shack that 
his father, and his grandfather (born a slave) lived in down in Alabama. 
Believe it or not, my dad's (born in 1926) grandfather was actually born a 
slave, freed shortly after birth by his owner father. I never met him, though. 
He died in the 40s.

Anyway, I cannot police all terms in the repo and do not wish to. This 
master/slave shit is archaic and mis-leading on technical grounds. Thankfully, 
there's only a handful of files in code and documentation that still talk about 
masters and slaves. We should replace all of them.

There are so many ways to reword it. In fact, unless anyone else objects or 
wants to do the grunt work to help my stress levels, I will open the pull 
request myself in effort to make this project and community more inviting to 
people of all backgrounds and histories. We can have leader/follower, or 
primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
garbage. 

 


> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal grandpa 
> in Alabama at four years old. He was a sharecropper before WWI, where he lost 
> his legs, and then he was back to being a sharecropper somehow after the war. 
> Crazy, I know. I don't know if the world still called his job sharecropping 
> in 1993, but he was basically a slave—in America. He lived in the same shack 
> that his father, and his grandfather (born a slave) lived in down in Alabama. 
> Believe it or not, my dad's (born in 1926) grandfather was actually born a 
> slave, freed shortly after birth by his owner father. I never met him, 
> though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and mis-leading on technical grounds. 
> Thankfully, there's only a handful of files in code and documentation that 
> still talk about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
> _Community over code._
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169479#comment-17169479
 ] 

Marcus Eagan edited comment on SOLR-14702 at 8/2/20, 8:09 AM:
--

[~o...@apache.org] and [~simonwillnauer] agree, ate least, on Twitter: 
[https://twitter.com/otisg/status/127361291415937]

 

Well, I know they both agree. They're both reasonable and kind.


was (Author: marcussorealheis):
[~o...@apache.org] and [~simonwillnauer] agree, ate least, on Twitter: 
https://twitter.com/otisg/status/127361291415937

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal grandpa 
> in Alabama at four years old. He was a sharecropper before WWI, where he lost 
> his legs, and then he was back to being a sharecropper somehow after the war. 
> Crazy, I know. I don't know if the world still called his job sharecropping 
> in 1993, but he was basically a slave—in America. He lived in the same shack 
> that his father, and his grandfather (born a slave) lived in down in Alabama. 
> Believe it or not, my dad's (born in 1926) grandfather was actually born a 
> slave, freed shortly after birth by his owner father. I never met him, 
> though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and mis-leading on technical grounds. 
> Thankfully, there's only a handful of files in code and documentation that 
> still talk about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169479#comment-17169479
 ] 

Marcus Eagan commented on SOLR-14702:
-

[~o...@apache.org] and [~simonwillnauer] agree, ate least, on Twitter: 
https://twitter.com/otisg/status/127361291415937

> Remove Master and Slave from Code Base and Docs
> ---
>
> Key: SOLR-14702
> URL: https://issues.apache.org/jira/browse/SOLR-14702
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Critical
>
> Every time I read _master_ and _slave_, I get pissed.
> I think about the last and only time I remember visiting my maternal grandpa 
> in Alabama at four years old. He was a sharecropper before WWI, where he lost 
> his legs, and then he was back to being a sharecropper somehow after the war. 
> Crazy, I know. I don't know if the world still called his job sharecropping 
> in 1993, but he was basically a slave—in America. He lived in the same shack 
> that his father, and his grandfather (born a slave) lived in down in Alabama. 
> Believe it or not, my dad's (born in 1926) grandfather was actually born a 
> slave, freed shortly after birth by his owner father. I never met him, 
> though. He died in the 40s.
> Anyway, I cannot police all terms in the repo and do not wish to. This 
> master/slave shit is archaic and mis-leading on technical grounds. 
> Thankfully, there's only a handful of files in code and documentation that 
> still talk about masters and slaves. We should replace all of them.
> There are so many ways to reword it. In fact, unless anyone else objects or 
> wants to do the grunt work to help my stress levels, I will open the pull 
> request myself in effort to make this project and community more inviting to 
> people of all backgrounds and histories. We can have leader/follower, or 
> primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
> garbage. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14702:
---

 Summary: Remove Master and Slave from Code Base and Docs
 Key: SOLR-14702
 URL: https://issues.apache.org/jira/browse/SOLR-14702
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (9.0)
Reporter: Marcus Eagan


Every time I read _master_ and _slave_, I get pissed.

I think about the last and only time I remember visiting my maternal grandpa in 
Alabama at four years old. He was a sharecropper before WWI, where he lost his 
legs, and then he was back to being a sharecropper somehow after the war. 
Crazy, I know. I don't know if the world still called his job sharecropping in 
1993, but he was basically a slave—in America. He lived in the same shack that 
his father, and his grandfather (born a slave) lived in down in Alabama. 
Believe it or not, my dad's (born in 1926) grandfather was actually born a 
slave, freed shortly after birth by his owner father. I never met him, though. 
He died in the 40s.

Anyway, I cannot police all terms in the repo and do not wish to. This 
master/slave shit is archaic and mis-leading on technical grounds. Thankfully, 
there's only a handful of files in code and documentation that still talk about 
masters and slaves. We should replace all of them.

There are so many ways to reword it. In fact, unless anyone else objects or 
wants to do the grunt work to help my stress levels, I will open the pull 
request myself in effort to make this project and community more inviting to 
people of all backgrounds and histories. We can have leader/follower, or 
primary/secondary, but none of this Master/Slave nonsense. I'm sick of the 
garbage. 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14701) Deprecate Schemaless Mode (Discussion)

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14701:
---

 Summary: Deprecate Schemaless Mode (Discussion)
 Key: SOLR-14701
 URL: https://issues.apache.org/jira/browse/SOLR-14701
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Schema and Analysis
Reporter: Marcus Eagan


I know this won't be the most popular ticket out there, but I am growing more 
and more sympathetic to the idea that we should rip many of the freedoms out 
that cause users more harm than not. One of the freedoms I saw time and time 
again to cause issues was schemaless mode. It doesn't work as named or 
documented, so I think it should be deprecated. 

If you use it in production reliably and in a way that cannot be accomplished 
another way, I am happy to hear from more knowledgeable folks as to why 
deprecation is a bad idea. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14681) Delete Jar with Command

[Marcus Eagan (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eagan updated SOLR-14681:

Description: 
We need to build logic that will delete a jar that represents a package. 

1. User should delete the zk entries of the files,
2. Call an http endpoint with DELETE method at /api/cluster/

  was:We need to build logic that will delete a jar that represents a package. 


> Delete Jar with Command
> ---
>
> Key: SOLR-14681
> URL: https://issues.apache.org/jira/browse/SOLR-14681
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Package Manager
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Assignee: Noble Paul
>Priority: Major
>
> We need to build logic that will delete a jar that represents a package. 
> 1. User should delete the zk entries of the files,
> 2. Call an http endpoint with DELETE method at /api/cluster/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14681) Delete Jar with Command

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17166236#comment-17166236
 ] 

Marcus Eagan commented on SOLR-14681:
-

^ Spam

> Delete Jar with Command
> ---
>
> Key: SOLR-14681
> URL: https://issues.apache.org/jira/browse/SOLR-14681
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Package Manager
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We need to build logic that will delete a jar that represents a package. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14681) Delete Jar with Command

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165410#comment-17165410
 ] 

Marcus Eagan commented on SOLR-14681:
-

[SOLR-14604 |https://issues.apache.org/jira/browse/SOLR-14604]needs this

> Delete Jar with Command
> ---
>
> Key: SOLR-14681
> URL: https://issues.apache.org/jira/browse/SOLR-14681
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Package Manager
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We need to build logic that will delete a jar that represents a package. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14681) Delete Jar with Command

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14681:
---

 Summary: Delete Jar with Command
 Key: SOLR-14681
 URL: https://issues.apache.org/jira/browse/SOLR-14681
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Package Manager
Affects Versions: master (9.0)
Reporter: Marcus Eagan


We need to build logic that will delete a jar that represents a package. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14664) Add Plugin Example for Docker

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14664:
---

 Summary: Add Plugin Example for Docker
 Key: SOLR-14664
 URL: https://issues.apache.org/jira/browse/SOLR-14664
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Marcus Eagan


With the release of 8.6.0 it seems to me that we should be adding an example of 
adding a plugin to the [docker-solr 
repo|[https://github.com/docker-solr/docker-solr]].

 

We could easily add the YASA plugin as an example to the 8.6.0 directory when 
it is created. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14603) Updating the Restlet Version

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151464#comment-17151464
 ] 

Marcus Eagan commented on SOLR-14603:
-

[~ichattopadhyaya] do you mind squash merging the PR against master?

> Updating the Restlet Version
> 
>
> Key: SOLR-14603
> URL: https://issues.apache.org/jira/browse/SOLR-14603
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build, Schema and Analysis
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
>
> There's not a whole lot of risk here because of the limited surface area of 
> Restlet in the project. [~ichattopadhyaya] even suggested we could remove it, 
> which I tend to agree with.
> I noticed that the Restlet dependency's location was no longer resolving at: 
> https://repo1.maven.org/maven2/org/restlet/jee/org.restlet/2.4.0/org.restlet-2.4.0.jar.
> Now, of course, I could change it to a location that does resolve or download 
> directly. However, I looking at the changelog I thought that maybe I should 
> raise with the community that it an upgrade might be helpful given the CVEs.
> I will leave it to the experts as to whether it makes a difference, but 
> here's the changelog for reference.
> The Lucene tests passed when I upgraded to 2.4.3 but I'm still digging in. It 
> is very likely that 2.4.1 would be better. I'd leave that, again, to the 
> experts and post my findings.
> https://github.com/apache/lucene-solr/pull/1622



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14611) Apache Pulsar Solr Plugin for CDCR

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14611:
---

 Summary: Apache Pulsar Solr Plugin for CDCR
 Key: SOLR-14611
 URL: https://issues.apache.org/jira/browse/SOLR-14611
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: CDCR, Plugin system
Affects Versions: master (9.0)
Reporter: Marcus Eagan


Solr CDCR is very fragile. It can cause a number of issues in environments with 
high querying or indexing load. 



@thelabdude has suggested a strong alternative in Apache Pulsar. Since it won’t 
be needed by all implementations, I suggest that this feature functionality be 
developed as a plugin to continue the strategy of keeping core Solr as lean as 
possible. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14034) remove deprecated min_rf references

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148972#comment-17148972
 ] 

Marcus Eagan commented on SOLR-14034:
-

[~rabikumar.kc] Do you still want to work on this or should someone else take 
it on? [~cpoerschke] has laid out the steps. Do you need help working with 
GitHub or anything?

> remove deprecated min_rf references
> ---
>
> Key: SOLR-14034
> URL: https://issues.apache.org/jira/browse/SOLR-14034
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Blocker
> Fix For: master (9.0)
>
>
> * {{min_rf}} support was added under SOLR-5468 in version 4.9 
> (https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.9.0/solr/solrj/src/java/org/apache/solr/client/solrj/request/UpdateRequest.java#L50)
>  and deprecated under SOLR-12767 in version 7.6 
> (https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.6.0/solr/solrj/src/java/org/apache/solr/client/solrj/request/UpdateRequest.java#L57-L61)
> * http://lucene.apache.org/solr/7_6_0/changes/Changes.html and 
> https://lucene.apache.org/solr/guide/8_0/major-changes-in-solr-8.html#solr-7-6
>  both clearly mention the deprecation
> This ticket is to fully remove {{min_rf}} references in code, tests and 
> documentation.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14022) Deprecate CDCR from Solr in 8.x

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148971#comment-17148971
 ] 

Marcus Eagan commented on SOLR-14022:
-

[~ichattopadhyaya][~ctargett][~thelabdude] Do you think we shoul build up a 
Pulsar plugin for Solr CDCR? That seems like it might be a very popular but not 
always necessary add-on. 

> Deprecate CDCR from Solr in 8.x
> ---
>
> Key: SOLR-14022
> URL: https://issues.apache.org/jira/browse/SOLR-14022
> Project: Solr
>  Issue Type: Improvement
>  Components: CDCR
>Reporter: Joel Bernstein
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.6
>
>
> This ticket will deprecate CDCR in Solr 8x.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14604) Uninstall Command for the Plugin Framework

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14604:
---

 Summary: Uninstall Command for the Plugin Framework
 Key: SOLR-14604
 URL: https://issues.apache.org/jira/browse/SOLR-14604
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Plugin system
Affects Versions: master (9.0)
Reporter: Marcus Eagan


I would like to be able to cleanly uninstall all artifacts associated with a 
plugin and the plugin itself from the command line. 

I'm not sure how many people want to work with the plugins yet, but as they 
grow in use and popularity, I'm sure this functionality will be desired by more 
people than just me. 

Today, the solution is to run the git command to remove all the files and 
directories that are un-versioned. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-9420) Restlet Dependency

[Marcus Eagan (Jira)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcus Eagan resolved LUCENE-9420.
--
Resolution: Fixed

closing and moving to SOLR project for now.

> Restlet Dependency
> --
>
> Key: LUCENE-9420
> URL: https://issues.apache.org/jira/browse/LUCENE-9420
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/other
>Reporter: Marcus Eagan
>Priority: Minor
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> I noticed that the Restlet dependency's location was no longer resolving at: 
> https://repo1.maven.org/maven2/org/restlet/jee/org.restlet/2.4.0/org.restlet-2.4.0.jar.
> Now, of course, I could change it to a location that does resolve or download 
> directly. However, I looking at the changelog I thought that maybe I should 
> raise with the community that it an upgrade might be helpful given the CVEs. 
> I will leave it to the experts as to whether it makes a difference, but 
> here's [the changelog for 
> reference|https://restlet.talend.com/documentation/2.4/changelog].
>  The Lucene tests passed when I upgraded to 2.4.3 but I'm still digging in. 
> It is very likely that 2.4.1 would be better. I'd leave that, again, to the 
> experts and post my findings.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (LUCENE-9420) Restlet Dependency

[Marcus Eagan (Jira)]

Marcus Eagan created LUCENE-9420:


 Summary: Restlet Dependency
 Key: LUCENE-9420
 URL: https://issues.apache.org/jira/browse/LUCENE-9420
 Project: Lucene - Core
  Issue Type: New Feature
  Components: core/other
Reporter: Marcus Eagan


I noticed that the Restlet dependency's location was no longer resolving at: 
https://repo1.maven.org/maven2/org/restlet/jee/org.restlet/2.4.0/org.restlet-2.4.0.jar.

Now, of course, I could change it to a location that does resolve or download 
directly. However, I looking at the changelog I thought that maybe I should 
raise with the community that it an upgrade might be helpful given the CVEs. 

I will leave it to the experts as to whether it makes a difference, but here's 
[the changelog for 
reference|https://restlet.talend.com/documentation/2.4/changelog].

 The Lucene tests passed when I upgraded to 2.4.3 but I'm still digging in. It 
is very likely that 2.4.1 would be better. I'd leave that, again, to the 
experts and post my findings.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13749) Implement support for joining across collections with multiple shards ( XCJF )

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17145101#comment-17145101
 ] 

Marcus Eagan commented on SOLR-13749:
-






> Implement support for joining across collections with multiple shards ( XCJF )
> --
>
> Key: SOLR-13749
> URL: https://issues.apache.org/jira/browse/SOLR-13749
> Project: Solr
>  Issue Type: New Feature
>Reporter: Kevin Watters
>Assignee: Gus Heck
>Priority: Blocker
> Fix For: 8.6
>
> Attachments: 2020-03 Smiley with ASF hat.jpeg
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> This ticket includes 2 query parsers.
> The first one is the "Cross collection join filter"  (XCJF) parser. This is 
> the "Cross-collection join filter" query parser. It can do a call out to a 
> remote collection to get a set of join keys to be used as a filter against 
> the local collection.
> The second one is the Hash Range query parser that you can specify a field 
> name and a hash range, the result is that only the documents that would have 
> hashed to that range will be returned.
> This query parser will do an intersection based on join keys between 2 
> collections.
> The local collection is the collection that you are searching against.
> The remote collection is the collection that contains the join keys that you 
> want to use as a filter.
> Each shard participating in the distributed request will execute a query 
> against the remote collection.  If the local collection is setup with the 
> compositeId router to be routed on the join key field, a hash range query is 
> applied to the remote collection query to only match the documents that 
> contain a potential match for the documents that are in the local shard/core. 
>  
>  
> Here's some vocab to help with the descriptions of the various parameters.
> ||Term||Description||
> |Local Collection|This is the main collection that is being queried.|
> |Remote Collection|This is the collection that the XCJFQuery will query to 
> resolve the join keys.|
> |XCJFQuery|The lucene query that executes a search to get back a set of join 
> keys from a remote collection|
> |HashRangeQuery|The lucene query that matches only the documents whose hash 
> code on a field falls within a specified range.|
>  
>  
> ||Param ||Required ||Description||
> |collection|Required|The name of the external Solr collection to be queried 
> to retrieve the set of join key values ( required )|
> |zkHost|Optional|The connection string to be used to connect to Zookeeper.  
> zkHost and solrUrl are both optional parameters, and at most one of them 
> should be specified.  
> If neither of zkHost or solrUrl are specified, the local Zookeeper cluster 
> will be used. ( optional )|
> |solrUrl|Optional|The URL of the external Solr node to be queried ( optional 
> )|
> |from|Required|The join key field name in the external collection ( required 
> )|
> |to|Required|The join key field name in the local collection|
> |v|See Note|The query to be executed against the external Solr collection to 
> retrieve the set of join key values.  
> Note:  The original query can be passed at the end of the string or as the 
> "v" parameter.  
> It's recommended to use query parameter substitution with the "v" parameter 
> to ensure no issues arise with the default query parsers.|
> |routed| |true / false.  If true, the XCJF query will use each shard's hash 
> range to determine the set of join keys to retrieve for that shard.
> This parameter improves the performance of the cross-collection join, but 
> it depends on the local collection being routed by the toField.  If this 
> parameter is not specified, 
> the XCJF query will try to determine the correct value automatically.|
> |ttl| |The length of time that an XCJF query in the cache will be considered 
> valid, in seconds.  Defaults to 3600 (one hour).  
> The XCJF query will not be aware of changes to the remote collection, so 
> if the remote collection is updated, cached XCJF queries may give inaccurate 
> results.  
> After the ttl period has expired, the XCJF query will re-execute the join 
> against the remote collection.|
> |_All others_| |Any normal Solr parameter can also be specified as a local 
> param.|
>  
> Example Solr Config.xml changes:
>  
>  {{<}}{{cache}} {{name}}{{=}}{{"hash_vin"}}
>  {{   }}{{class}}{{=}}{{"solr.LRUCache"}}
>  {{   }}{{size}}{{=}}{{"128"}}
>  {{   }}{{initialSize}}{{=}}{{"0"}}
>  {{   }}{{regenerator}}{{=}}{{"solr.NoOpRegenerator"}}{{/>}}
>   
>  {{<}}{{queryParser}} {{name}}{{=}}{{"xcjf"}} 
> {{class}}{{=}}{{"org.apache.solr.search.join.XCJFQueryParserPlugin"}}{{>}}
>  {{  }}{{<}}{{str}} {{name}}{{=}}{{"routerField"}}{{>vin}}
>  {{}}
>   
>  {{<}}{{queryParser}} 

[jira] [Commented] (SOLR-14578) Confusing Name in the docs and Test of Auto Add Trigger

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17138939#comment-17138939
 ] 

Marcus Eagan commented on SOLR-14578:
-

[https://github.com/apache/lucene-solr/pull/1591]

> Confusing Name in the docs and Test of Auto Add Trigger
> ---
>
> Key: SOLR-14578
> URL: https://issues.apache.org/jira/browse/SOLR-14578
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Trivial
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In the autoscaling docs, the name of the names of two actions are the same 
> and it is confusing to users.
> See:
> {code:java}
> {
>   "set-trigger": {
> "name": ".auto_add_replicas",
> "event": "nodeLost,
> "waitFor": "5s",
> "enabled": true,
> "actions": [
>   {
> "name": "auto_add_replicas_plan",
> "class": "solr.AutoAddReplicasPlanAction"
>   },
>   {
>"name": "auto_add_replicas_plan", // works?, but should be execute plan
>"class": "solr.ExecutePlanAction"
>   }
> ]
>   }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14578) Confusing Name in the docs and Test of Auto Add Trigger

[Marcus Eagan (Jira)]

Marcus Eagan created SOLR-14578:
---

 Summary: Confusing Name in the docs and Test of Auto Add Trigger
 Key: SOLR-14578
 URL: https://issues.apache.org/jira/browse/SOLR-14578
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: AutoScaling
Affects Versions: master (9.0)
Reporter: Marcus Eagan


In the autoscaling docs, the name of the names of two actions are the same and 
it is confusing to users.

See:
{code:java}
{
  "set-trigger": {
"name": ".auto_add_replicas",
"event": "nodeLost,
"waitFor": "5s",
"enabled": true,
"actions": [
  {
"name": "auto_add_replicas_plan",
"class": "solr.AutoAddReplicasPlanAction"
  },
  {
   "name": "auto_add_replicas_plan", // works?, but should be execute plan
   "class": "solr.ExecutePlanAction"
  }
]
  }
}
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14414) New Admin UI

[Marcus Eagan (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095592#comment-17095592
 ] 

Marcus Eagan commented on SOLR-14414:
-

looking back at this one from the homie [~uboness]. One for the history books: 
https://issues.apache.org/jira/browse/SOLR-1163

> New Admin UI
> 
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
> Attachments: QueryUX-SolrAdminUIReboot.mov
>
>
> We have had a lengthy discussion in the mailing list about the need to build 
> a modern UI that is both more security and does not depend on deprecated, end 
> of life code. In this ticket, I intend to familiarize the community with the 
> efforts of the community to do just that that. While we are nearing feature 
> parity, but not there yet as many have suggested we could complete this task 
> in iterations, here is an attempt to get the ball rolling. I have mostly 
> worked on it in weekend nights on the occasion that I could find the time. 
> Angular is certainly not my specialty, and this is my first attempt at using 
> TypeScript besides a few brief learning exercises here and there. However, I 
> will be engaging experts in both of these areas for consultation as our 
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be 
> rewritten, and there are even at least three essential components to the app 
> missing, along with some tests. A couple other things missing are the V2 API, 
>  which I found difficult to build with in this context because it is not 
> documented on the web. I understand that it is "self-documenting," but the 
> most easy-to-use APIs are still documented on the web. Maybe it is entirely 
> documented on the web, and I had trouble finding it. Forgive me, as that 
> could be an area of assistance. Another area where I need assistance is 
> packaging this application as a Solr package. I understand this app is not in 
> the right place for that today, but it can be. There are still many 
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a 
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It 
> can quickly be modified to start as a part of the typical start commands as 
> it approaches parity. I expect there will be a lot of opinions. I welcome 
> them, of course. The community input should drive the project's success. 
> Discussion in mailing list: 
> https://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3CCAF76exK-EB_tyFx0B4fBiA%3DJj8gH%3Divn2Uo6cWvMwhvzRdA3KA%40mail.gmail.com%3E



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org