[jira] [Commented] (SOLR-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)

[David Smiley (Jira)]

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

David Smiley commented on SOLR-14557:
-

Is there really no fix aside from using \_query_ ?  I view that as very legacy 
that ought to go away some day.  Solr doesn't need two ways to do the same 
thing... we add new better ways but not remove the old :-/

> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
>  Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}} 
>  
>  goes like
>  {code}
>  \{!lucene}(foo)
>  content:foo
>  LuceneQParser
> {code}
> fine
> h2. Solr 8.2 
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but 
> it's a question of migrating existing queries. 
> {{/select?defType=edismax=\{!lucene}(foo)=true}} 
> goes like 
> {code}
> "querystring":"\{!lucene}(foo)",
>  "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene 
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo) 
>  "QParser":"ExtendedDismaxQParser",
> {code}
> blah... 
> but removing braces in 8.2 works perfectly fine 
> {code}
> "querystring":"\{!lucene}foo",
>  "parsedquery":"+content:foo",
>  "parsedquery_toString":"+content:foo",
>  "QParser":"ExtendedDismaxQParser",
>  {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] [Comment Edited] (SOLR-14704) Add download option to solr/cloud-dev/cloud.sh

[Gus Heck (Jira)]

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

Gus Heck edited comment on SOLR-14704 at 8/3/20, 3:57 AM:
--

For example: 

{code:java}
./cloud.sh new -d 
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC1-reva32a3ac4e43f629df71e5ae30a3330be94b095f2/solr/solr-8.6.1.tgz
 8_6_1_RC1
{code}



was (Author: gus_heck):
For example: 

{code:java}
./cloud.sh new -t 
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC1-reva32a3ac4e43f629df71e5ae30a3330be94b095f2/solr/solr-8.6.1.tgz
 8_6_1_RC1
{code}


> Add download option to solr/cloud-dev/cloud.sh
> --
>
> Key: SOLR-14704
> URL: https://issues.apache.org/jira/browse/SOLR-14704
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For easier testing of things like RC artifacts I'm adding an option to 
> cloud.sh which will curl a tarball down from the web instead of building it 
> locally.



--
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-14704) Add download option to solr/cloud-dev/cloud.sh

[Gus Heck (Jira)]

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

Gus Heck commented on SOLR-14704:
-

For example: 

{code:java}
./cloud.sh new -t 
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC1-reva32a3ac4e43f629df71e5ae30a3330be94b095f2/solr/solr-8.6.1.tgz
 8_6_1_RC1
{code}


> Add download option to solr/cloud-dev/cloud.sh
> --
>
> Key: SOLR-14704
> URL: https://issues.apache.org/jira/browse/SOLR-14704
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For easier testing of things like RC artifacts I'm adding an option to 
> cloud.sh which will curl a tarball down from the web instead of building it 
> locally.



--
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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#issuecomment-667788473


   Looks like `doTestStressReplicaion` is a confirmed Bad Apple as defined 
here: https://issues.apache.org/jira/browse/SOLR-12028
   
   In other words, moving on to check the others. I'll batch my comments 
accordingly. 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#issuecomment-667786472


   I ran it again and shard split tests didn't fail so there seems to be some 
inconsistency there. ReplicationHandler tests still failed. I'm digging as to 
what they test to see if I can determine why they don't fail when isolated but 
do fail when run together.
   
   See below:
   
   ```
   [junit4]   - 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication
   [junit4]   - org.apache.solr.handler.TestReplicationHandler.doTestRepeater
   [junit4]   - 
org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication
   [junit4]   - 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl
   ```
   
   So strange



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] gus-asf opened a new pull request #1715: SOLR-14704 download option

[GitBox]

gus-asf opened a new pull request #1715:
URL: https://github.com/apache/lucene-solr/pull/1715


   Initial cut at this, only tested on mac osx so far.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Created] (SOLR-14704) Add download option to solr/cloud-dev/cloud.sh

[Gus Heck (Jira)]

Gus Heck created SOLR-14704:
---

 Summary: Add download option to solr/cloud-dev/cloud.sh
 Key: SOLR-14704
 URL: https://issues.apache.org/jira/browse/SOLR-14704
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Reporter: Gus Heck
Assignee: Gus Heck


For easier testing of things like RC artifacts I'm adding an option to cloud.sh 
which will curl a tarball down from the web instead of building it locally.



--
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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1710: SOLR-14604: Uninstall package cli command

[GitBox]

MarcusSorealheis commented on pull request #1710:
URL: https://github.com/apache/lucene-solr/pull/1710#issuecomment-667773267


   >There is a precommit failure due to some class cast exception. I think I 
can tackle that at the time of merging. Thanks for getting this feature in!
   
   Open with in the upper right of the PR conversation menu there is an open 
with. If you are running unix, I recommend using homebrew to install the `gh` 
cli and checkout out the PR. It's really easily if you'd like to make a change. 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
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

[Noble Paul (Jira)]

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

Noble Paul commented on SOLR-14702:
---

I suggest we stick to one naming convention. leader follower (for both 
standalone and cluster 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
>  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

[GitHub] [lucene-solr] noblepaul opened a new pull request #1714: Assign sdk based on the new public APIs

[GitBox]

noblepaul opened a new pull request #1714:
URL: https://github.com/apache/lucene-solr/pull/1714


   for review and discussion purposes



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
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)

[Noble Paul (Jira)]

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

Noble Paul commented on SOLR-14701:
---

[~erickerickson] 
I like that suggestion. Other than the {{id}} field, everything can be  
collected into that catch-all dynamic-field. The current schemaless is no 
better than this solution. 

We have built monsters into Solr code without evaluating if it is really useful 
to our users. These "features" subtract value from the product with added code 
complexity & documentation challenges

I'm +1 to removing schemaless mode altogether.


bq.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. 

Excellent point. We seem to discuss too many things in mailing lists and 
ultimately nothing gets done. The solution is to force the hands of devs by 
creating a JIRA & a PR. This way we are forced to either let it happen or do a 
{{-1}} (veto). When we give  a veto , we are forced to come up with a real 
technical reason for it. We need to ensure that the "armchair developers" do 
not run the project & let the real doers take over.  



> 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

[GitHub] [lucene-solr] MarcusSorealheis edited a comment on pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis edited a comment on pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#issuecomment-667748906


   I've gone through and tested these classes individually and they all pass, 
yet these tests fail when run with the entire project:
   
   ```[junit4] Tests with failures [seed: 2F07E49425A06B54]:
  [junit4]   - 
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit
  [junit4]   - 
org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication
  [junit4]   - org.apache.solr.handler.TestReplicationHandler.doTestRepeater
  [junit4]   - 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication
  [junit4]   - 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl
  [junit4]   - org.apache.solr.cloud.api.collections.ShardSplitTest (suite)
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#issuecomment-667749162


   This suggests to me that there must be some shared state that exists between 
other tests in the suite or there is flakiness. I don't know anything about the 
flakiness. Inly know that there are flaky tests. Does anyone have any idea what 
I'm missing. CC @chatman @murblanc 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#issuecomment-667748906


   I've gone through and tested these classes individually and they all pass, 
yet these tests fail when run with the entire project:
   
   ```[junit4] Tests with failures [seed: 2F07E49425A06B54]:
  [junit4]   - 
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit
  [junit4]   - 
org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication
  [junit4]   - org.apache.solr.handler.TestReplicationHandler.doTestRepeater
  [junit4]   - 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication
  [junit4]   - 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl
  [junit4]   - org.apache.solr.cloud.api.collections.ShardSplitTest 
(suite)```
   
   This suggests to me that there must be some shared state that exists between 
other tests in the suite or there is flakiness. I don't know anything about the 
flakiness. Inly know that there are flaky tests. Does anyone have any idea what 
I'm missing. CC @chatman @murblanc 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#issuecomment-667748559


   This also passes: 
   
![image](https://user-images.githubusercontent.com/2353608/89136223-6bd6e200-d4e7-11ea-8c1e-96a87de73f64.png)
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#issuecomment-667748404


   @chatman it looks like the tests pass when I run the TestReplicationHandler 
on its own but it fails when I run ant test locally: 
   
![image](https://user-images.githubusercontent.com/2353608/89136063-91afb700-d4e6-11ea-9f25-1147f8825815.png)
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Commented] (SOLR-14613) Provide a clean API for pluggable replica assignment implementations

[Ilan Ginzburg (Jira)]

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

Ilan Ginzburg commented on SOLR-14613:
--

I'm getting closer to being happy with the interfaces. Will add whatever other 
computation needs there are (by reviewing all Collection API command 
implementations). I've simplified quite a bit from last week, and sticking 
closer to current Collection API and Overseer state change implementations so 
writing the Solr side code driving these interfaces will be relatively simple.

I'm keeping the {{Cluster}}, {{SolrCollection}}, {{Shard}}, {{Replica}} 
abstractions originally introduced in this PR for now and not switching right 
away to use those being defined in [PR 
1694|https://github.com/apache/lucene-solr/pull/1694]. Once 1694 is complete 
with examples (and committed) I'll see how much more complex/simple/efficient 
plugin (and Solr side implementation) code is made by using 1694 abstractions 
and will decide to either expose them directly to plugins or use a layer on top 
of them and keep the abstractions as defined here.

> Provide a clean API for pluggable replica assignment implementations
> 
>
> Key: SOLR-14613
> URL: https://issues.apache.org/jira/browse/SOLR-14613
> Project: Solr
>  Issue Type: Improvement
>  Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Ilan Ginzburg
>Priority: Major
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> As described in SIP-8 the current autoscaling Policy implementation has 
> several limitations that make it difficult to use for very large clusters and 
> very large collections. SIP-8 also mentions the possible migration path by 
> providing alternative implementations of the placement strategies that are 
> less complex but more efficient in these very large environments.
> We should review the existing APIs that the current autoscaling engine uses 
> ({{SolrCloudManager}} , {{AssignStrategy}} , {{Suggester}} and related 
> interfaces) to see if they provide a sufficient and minimal API for plugging 
> in alternative autoscaling placement strategies, and if necessary refactor 
> the existing APIs.
> Since these APIs are internal it should be possible to do this without 
> breaking back-compat.



--
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

[GitHub] [lucene-solr] yuriy-b-koval opened a new pull request #1713: SOLR-14703 Edismax parser replaces whitespace characters with spaces

[GitBox]

yuriy-b-koval opened a new pull request #1713:
URL: https://github.com/apache/lucene-solr/pull/1713


   
   
   
   # Description
   
   Please provide a short description of the changes you're making with this 
pull request.
   
   # Solution
   
   Please provide a short description of the approach taken to implement your 
solution.
   
   # Tests
   
   Please describe the tests you've developed or run to confirm this patch 
implements the feature or solves the problem.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ ] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [ ] I have developed this patch against the `master` branch.
   - [ ] I have run `ant precommit` and the appropriate test suite.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464142802



##
File path: solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java
##
@@ -1241,33 +1241,33 @@ public void inform(SolrCore core) {
   numberBackupsToKeep = 0;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList slave = (NamedList) initArgs.get("slave");
-boolean enableSlave = isEnabled( slave );
-if (enableSlave) {
-  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(slave, 
this, core);
-  setupPolling((String) slave.get(POLL_INTERVAL));
-  isSlave = true;
+NamedList secondary = (NamedList) initArgs.get("secondary");
+boolean enableSecondary = isEnabled( secondary );
+if (enableSecondary) {
+  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(secondary, 
this, core);
+  setupPolling((String) secondary.get(POLL_INTERVAL));
+  isSecondary = true;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList master = (NamedList) initArgs.get("master");
-boolean enableMaster = isEnabled( master );
+NamedList primary = (NamedList) initArgs.get("primary");

Review comment:
   I changed it to this: `NamedList primary = 
(NamedList)(initArgs.get("primary") != null ? initArgs.get("primary") : 
initArgs.get("master"));`
   





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] murblanc commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

murblanc commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464141895



##
File path: solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java
##
@@ -1241,33 +1241,33 @@ public void inform(SolrCore core) {
   numberBackupsToKeep = 0;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList slave = (NamedList) initArgs.get("slave");
-boolean enableSlave = isEnabled( slave );
-if (enableSlave) {
-  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(slave, 
this, core);
-  setupPolling((String) slave.get(POLL_INTERVAL));
-  isSlave = true;
+NamedList secondary = (NamedList) initArgs.get("secondary");
+boolean enableSecondary = isEnabled( secondary );
+if (enableSecondary) {
+  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(secondary, 
this, core);
+  setupPolling((String) secondary.get(POLL_INTERVAL));
+  isSecondary = true;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList master = (NamedList) initArgs.get("master");
-boolean enableMaster = isEnabled( master );
+NamedList primary = (NamedList) initArgs.get("primary");

Review comment:
   As @chatman commented in the general discussion, maybe these changes 
happening in a new major version branch does no require them to be 
backward/forward compatible?
   
   If 8x and 9.0 servers are expected to talk and understand each other, the 
suggestion looks good on the receiving end. We need something on the sending 
end as well (send both values, because "primary" being sent to a 8x server 
expecting only "master" will not be understood).





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Updated] (SOLR-14703) Edismax parser replaces whitespace characters with spaces

[Yuriy Koval (Jira)]

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

Yuriy Koval updated SOLR-14703:
---
Summary: Edismax parser replaces whitespace characters with spaces  (was: 
Edismax parser replaces whitespace characters to spaces)

> Edismax parser replaces whitespace characters with spaces
> -
>
> Key: SOLR-14703
> URL: https://issues.apache.org/jira/browse/SOLR-14703
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 8.4.1
>Reporter: Yuriy Koval
>Priority: Minor
>
> If, in an expression, a value with a whitespace char is directly preceded by 
> a special char "[" or "(", whitespace char in the value gets replaced with 
> space.
> This does not happen, if there is a space between "[" and a double quote in 
> the expression.
> For example, if we have a document with cat_s field containing a value 
> "57\n157", following query works:
> {noformat}
> "q":"cat_s:[ \"57\n157\" TO \"57\n157\"]",
> "defType":"edismax"{noformat}
> but
> {noformat}
> "q":"cat_s:[\"57\n157\" TO \"57\n157\"]",
> "defType":"edismax{noformat}
> does not, as lower boundary value gets replaces with "57 157" in 
> ExtendedDismaxQParser after following calls
> {code:java}
> List clauses = splitIntoClauses(userQuery, false);
> String mainUserQuery = rebuildUserQuery(clauses, 
> config.lowercaseOperators);{code}
> As a workaround, we need to add a space before a double quote in expressions.



--
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-14703) Edismax parser replaces whitespace characters to spaces

[Yuriy Koval (Jira)]

Yuriy Koval created SOLR-14703:
--

 Summary: Edismax parser replaces whitespace characters to spaces
 Key: SOLR-14703
 URL: https://issues.apache.org/jira/browse/SOLR-14703
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: query parsers
Affects Versions: 8.4.1
Reporter: Yuriy Koval


If, in an expression, a value with a whitespace char is directly preceded by a 
special char "[" or "(", whitespace char in the value gets replaced with space.

This does not happen, if there is a space between "[" and a double quote in the 
expression.

For example, if we have a document with cat_s field containing a value 
"57\n157", following query works:
{noformat}
"q":"cat_s:[ \"57\n157\" TO \"57\n157\"]",
"defType":"edismax"{noformat}
but
{noformat}
"q":"cat_s:[\"57\n157\" TO \"57\n157\"]",
"defType":"edismax{noformat}
does not, as lower boundary value gets replaces with "57 157" in 
ExtendedDismaxQParser after following calls
{code:java}
List clauses = splitIntoClauses(userQuery, false);
String mainUserQuery = rebuildUserQuery(clauses, 
config.lowercaseOperators);{code}
As a workaround, we need to add a space before a double quote in expressions.



--
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

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464140926



##
File path: solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java
##
@@ -1241,33 +1241,33 @@ public void inform(SolrCore core) {
   numberBackupsToKeep = 0;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList slave = (NamedList) initArgs.get("slave");
-boolean enableSlave = isEnabled( slave );
-if (enableSlave) {
-  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(slave, 
this, core);
-  setupPolling((String) slave.get(POLL_INTERVAL));
-  isSlave = true;
+NamedList secondary = (NamedList) initArgs.get("secondary");
+boolean enableSecondary = isEnabled( secondary );
+if (enableSecondary) {
+  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(secondary, 
this, core);
+  setupPolling((String) secondary.get(POLL_INTERVAL));
+  isSecondary = true;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList master = (NamedList) initArgs.get("master");
-boolean enableMaster = isEnabled( master );
+NamedList primary = (NamedList) initArgs.get("primary");

Review comment:
   `initArgs.containsKey("primary") ? initArgs.get("primary") : 
initArgs.get("master")`?





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#issuecomment-667742202


   After all the recent changes, making sure the tests pass



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464139788



##
File path: solr/solr-ref-guide/src/query-settings-in-solrconfig.adoc
##
@@ -203,7 +203,7 @@ This setting controls whether search requests for which 
there is not a currently
 
 === maxWarmingSearchers
 
-This parameter sets the maximum number of searchers that may be warming up in 
the background at any given time. Exceeding this limit will raise an error. For 
read-only slaves, a value of two is reasonable. Masters should probably be set 
a little higher.
+This parameter sets the maximum number of searchers that may be warming up in 
the background at any given time. Exceeding this limit will raise an error. For 
read-only secondaries, a value of two is reasonable. Primarys should probably 
be set a little higher.

Review comment:
   I've made this change @chatman 





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1710: SOLR-14604: Uninstall package cli command

[GitBox]

MarcusSorealheis commented on pull request #1710:
URL: https://github.com/apache/lucene-solr/pull/1710#issuecomment-667741261


   Thanks for the review! :)
   
   On Sun, Aug 2, 2020 at 4:27 PM Ishan Chattopadhyaya <
   notificati...@github.com> wrote:
   
   > There is a precommit failure due to some class cast exception. I think I
   > can tackle that at the time of merging. Thanks for getting this feature in!
   >
   > —
   > You are receiving this because you modified the open/close state.
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   >
   
   
   -- 
   Marcus Eagan
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464138343



##
File path: solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java
##
@@ -1241,33 +1241,33 @@ public void inform(SolrCore core) {
   numberBackupsToKeep = 0;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList slave = (NamedList) initArgs.get("slave");
-boolean enableSlave = isEnabled( slave );
-if (enableSlave) {
-  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(slave, 
this, core);
-  setupPolling((String) slave.get(POLL_INTERVAL));
-  isSlave = true;
+NamedList secondary = (NamedList) initArgs.get("secondary");
+boolean enableSecondary = isEnabled( secondary );
+if (enableSecondary) {
+  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(secondary, 
this, core);
+  setupPolling((String) secondary.get(POLL_INTERVAL));
+  isSecondary = true;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList master = (NamedList) initArgs.get("master");
-boolean enableMaster = isEnabled( master );
+NamedList primary = (NamedList) initArgs.get("primary");

Review comment:
   I'm going to look through it. Hopefully I can grok it. Not sure, though. 
If I can find a more backcompat approach, I will drop it in the PR. Open to 
suggestions from others.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] chatman commented on pull request #1710: SOLR-14604: Uninstall package cli command

[GitBox]

chatman commented on pull request #1710:
URL: https://github.com/apache/lucene-solr/pull/1710#issuecomment-667738758


   There is a precommit failure due to some class cast exception. I think I can 
tackle that at the time of merging. Thanks for getting this feature in!



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464134375



##
File path: solr/solr-ref-guide/src/query-settings-in-solrconfig.adoc
##
@@ -203,7 +203,7 @@ This setting controls whether search requests for which 
there is not a currently
 
 === maxWarmingSearchers
 
-This parameter sets the maximum number of searchers that may be warming up in 
the background at any given time. Exceeding this limit will raise an error. For 
read-only slaves, a value of two is reasonable. Masters should probably be set 
a little higher.
+This parameter sets the maximum number of searchers that may be warming up in 
the background at any given time. Exceeding this limit will raise an error. For 
read-only secondaries, a value of two is reasonable. Primarys should probably 
be set a little higher.

Review comment:
   ok that's a good suggestion. Primarys was another typo. I'll add it.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
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] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs

[Erick Erickson (Jira)]

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

Erick Erickson commented on SOLR-14702:
---

I can adapt to whichever convention is most convenient

> 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 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

[GitHub] [lucene-solr] chatman commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

chatman commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464133924



##
File path: solr/solr-ref-guide/src/query-settings-in-solrconfig.adoc
##
@@ -203,7 +203,7 @@ This setting controls whether search requests for which 
there is not a currently
 
 === maxWarmingSearchers
 
-This parameter sets the maximum number of searchers that may be warming up in 
the background at any given time. Exceeding this limit will raise an error. For 
read-only slaves, a value of two is reasonable. Masters should probably be set 
a little higher.
+This parameter sets the maximum number of searchers that may be warming up in 
the background at any given time. Exceeding this limit will raise an error. For 
read-only secondaries, a value of two is reasonable. Primarys should probably 
be set a little higher.

Review comment:
   Instead of "secondaries" and "primaries" (or "primarys"), lets call them 
"primary servers" and "secondary servers" in the reference guide.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#issuecomment-667730192


   > PR description says:
   > 
   > > Replaces master with leader and slave with follower.
   > 
   > Actual replacement is primary/secondary.
   > 
   I've fixed the description. That was a vestige of my initial PR where I ran 
into problems when I tried to run/understand the changes. 
   
   > I don't see the renamed `.png` files. Are they part of a different PR?
   
   On the PNG's, I've fixed them. I was aware of them and forgot to address. I 
think subsequent PRs will follow, but haven't determined the scope yet. I want 
to move away from surface level fixes that have deeply emotional implications 
for code readers and developers on a social level to surface level fixes that 
have deeply emotional implications for code readers on a technical level. Lots 
of words there. **Better developer experience.** 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464128075



##
File path: 
solr/core/src/java/org/apache/solr/security/JWTVerificationkeyResolver.java
##
@@ -106,7 +106,7 @@ public Key resolveKey(JsonWebSignature jws, 
List nestingContex
 }
   }
 
-  // Add all keys into a master list
+  // Add all keys into a primary list

Review comment:
   yea, that was a screw up of mine. I would say this can stay master as I 
have no inherent problem with the word `master` outside of the context of 
`master/slave`.
   
   However, I agree that probably best to remove this one in this case because 
others do.  I'll change it to reference. 





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Updated] (SOLR-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)

[Mikhail Khludnev (Jira)]

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

Mikhail Khludnev updated SOLR-14557:

Resolution: Won't Fix
Status: Resolved  (was: Patch Available)

> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
>  Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}} 
>  
>  goes like
>  {code}
>  \{!lucene}(foo)
>  content:foo
>  LuceneQParser
> {code}
> fine
> h2. Solr 8.2 
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but 
> it's a question of migrating existing queries. 
> {{/select?defType=edismax=\{!lucene}(foo)=true}} 
> goes like 
> {code}
> "querystring":"\{!lucene}(foo)",
>  "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene 
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo) 
>  "QParser":"ExtendedDismaxQParser",
> {code}
> blah... 
> but removing braces in 8.2 works perfectly fine 
> {code}
> "querystring":"\{!lucene}foo",
>  "parsedquery":"+content:foo",
>  "parsedquery_toString":"+content:foo",
>  "QParser":"ExtendedDismaxQParser",
>  {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-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)

[Mikhail Khludnev (Jira)]

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

Mikhail Khludnev commented on SOLR-14557:
-

Ok. There are two places where local params are parsed:
# QParser.parseLocalParams() when string starts with curly brace { 
# JavaCC QueryParser.jj SOLR-4093 
SOLR-11501 banned edismax from the former option. But the former option is 
unable to handle {{\{!parser}(foo)}} that might seem like a bug, but after 
thinking a little I've though it's reasonable. Think about {{(\{!term}foo)}}, 
it should be parsed to {{foo}} undoubtedly, but {{\{!term}(foo)}} behavior 
quite depended on subordinate parser, TermQParser should receive parenthesis, 
but LuceneQParser probably shouldn't.
So, I resolved it just by advising customer for tweaking syntax: 
Before 7.2 {{\{!join ...}(... )}} -> after 7.2 {{\_query_:"\{!join ... 
defType=edixmax}."}}   
Sorry for the noise.

> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
>  Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}} 
>  
>  goes like
>  {code}
>  \{!lucene}(foo)
>  content:foo
>  LuceneQParser
> {code}
> fine
> h2. Solr 8.2 
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but 
> it's a question of migrating existing queries. 
> {{/select?defType=edismax=\{!lucene}(foo)=true}} 
> goes like 
> {code}
> "querystring":"\{!lucene}(foo)",
>  "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene 
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo) 
>  "QParser":"ExtendedDismaxQParser",
> {code}
> blah... 
> but removing braces in 8.2 works perfectly fine 
> {code}
> "querystring":"\{!lucene}foo",
>  "parsedquery":"+content:foo",
>  "parsedquery_toString":"+content:foo",
>  "QParser":"ExtendedDismaxQParser",
>  {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] [Assigned] (SOLR-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)

[Mikhail Khludnev (Jira)]

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

Mikhail Khludnev reassigned SOLR-14557:
---

Assignee: Mikhail Khludnev

> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
>  Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}} 
>  
>  goes like
>  {code}
>  \{!lucene}(foo)
>  content:foo
>  LuceneQParser
> {code}
> fine
> h2. Solr 8.2 
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but 
> it's a question of migrating existing queries. 
> {{/select?defType=edismax=\{!lucene}(foo)=true}} 
> goes like 
> {code}
> "querystring":"\{!lucene}(foo)",
>  "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene 
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo) 
>  "QParser":"ExtendedDismaxQParser",
> {code}
> blah... 
> but removing braces in 8.2 works perfectly fine 
> {code}
> "querystring":"\{!lucene}foo",
>  "parsedquery":"+content:foo",
>  "parsedquery_toString":"+content:foo",
>  "QParser":"ExtendedDismaxQParser",
>  {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-14613) Provide a clean API for pluggable replica assignment implementations

[Ilan Ginzburg (Jira)]

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

Ilan Ginzburg commented on SOLR-14613:
--

In [PR 1684|https://github.com/apache/lucene-solr/pull/1684] changed package 
name, removed unnecessary interfaces and started aligning work orders to 
Collection API commands to be able to simplify locking.

> Provide a clean API for pluggable replica assignment implementations
> 
>
> Key: SOLR-14613
> URL: https://issues.apache.org/jira/browse/SOLR-14613
> Project: Solr
>  Issue Type: Improvement
>  Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Ilan Ginzburg
>Priority: Major
>  Time Spent: 10h 10m
>  Remaining Estimate: 0h
>
> As described in SIP-8 the current autoscaling Policy implementation has 
> several limitations that make it difficult to use for very large clusters and 
> very large collections. SIP-8 also mentions the possible migration path by 
> providing alternative implementations of the placement strategies that are 
> less complex but more efficient in these very large environments.
> We should review the existing APIs that the current autoscaling engine uses 
> ({{SolrCloudManager}} , {{AssignStrategy}} , {{Suggester}} and related 
> interfaces) to see if they provide a sufficient and minimal API for plugging 
> in alternative autoscaling placement strategies, and if necessary refactor 
> the existing APIs.
> Since these APIs are internal it should be possible to do this without 
> breaking back-compat.



--
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

[GitHub] [lucene-solr] murblanc commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

murblanc commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464111546



##
File path: solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java
##
@@ -1241,33 +1241,33 @@ public void inform(SolrCore core) {
   numberBackupsToKeep = 0;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList slave = (NamedList) initArgs.get("slave");
-boolean enableSlave = isEnabled( slave );
-if (enableSlave) {
-  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(slave, 
this, core);
-  setupPolling((String) slave.get(POLL_INTERVAL));
-  isSlave = true;
+NamedList secondary = (NamedList) initArgs.get("secondary");
+boolean enableSecondary = isEnabled( secondary );
+if (enableSecondary) {
+  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(secondary, 
this, core);
+  setupPolling((String) secondary.get(POLL_INTERVAL));
+  isSecondary = true;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList master = (NamedList) initArgs.get("master");
-boolean enableMaster = isEnabled( master );
+NamedList primary = (NamedList) initArgs.get("primary");

Review comment:
   Also same issue in the other direction: if an updated node sends 
"primary" to a non updated node expecting "master", the non updated node will 
fail. Maybe we need to send the same data under both "primary" and "master" and 
the same data under both "secondary" and "slave", and accept either one on the 
receiving end.
   
   I'm not familiar with how this code exactly works so might be off here, but 
this rename is not internal so must use caution (and test with renamed nodes 
talking to non renamed nodes, on both roles).





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] murblanc commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

murblanc commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r46468



##
File path: solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java
##
@@ -1241,33 +1241,33 @@ public void inform(SolrCore core) {
   numberBackupsToKeep = 0;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList slave = (NamedList) initArgs.get("slave");
-boolean enableSlave = isEnabled( slave );
-if (enableSlave) {
-  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(slave, 
this, core);
-  setupPolling((String) slave.get(POLL_INTERVAL));
-  isSlave = true;
+NamedList secondary = (NamedList) initArgs.get("secondary");
+boolean enableSecondary = isEnabled( secondary );
+if (enableSecondary) {
+  currentIndexFetcher = pollingIndexFetcher = new IndexFetcher(secondary, 
this, core);
+  setupPolling((String) secondary.get(POLL_INTERVAL));
+  isSecondary = true;
 }
 @SuppressWarnings({"rawtypes"})
-NamedList master = (NamedList) initArgs.get("master");
-boolean enableMaster = isEnabled( master );
+NamedList primary = (NamedList) initArgs.get("primary");

Review comment:
   Isn't this a communication between different Solr nodes?
   If the current node got updated to new vocabulary primary/secondary but the 
remote node did not and did send data using master/slave, we might run into 
issues.
   
   It might be desirable (if the above is true) to support both primary and 
master as return values (and secondary and slave) until a subsequent version of 
Solr not expected to work with nodes running code using master/slave.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] murblanc commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

murblanc commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464110429



##
File path: 
solr/core/src/java/org/apache/solr/security/JWTVerificationkeyResolver.java
##
@@ -106,7 +106,7 @@ public Key resolveKey(JsonWebSignature jws, 
List nestingContex
 }
   }
 
-  // Add all keys into a master list
+  // Add all keys into a primary list

Review comment:
   This occurrence of "master" is unrelated to master/slave replication. 
Maybe simply remove the word "master" or replace it with "reference" but 
"primary" doesn't really make sense.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] murblanc commented on pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

murblanc commented on pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#issuecomment-667710021


   PR description says:
   > Replaces master with leader and slave with follower.
   
   Actual replacement is primary/secondary.
   
   I don't see the renamed `.png` files. Are they part of a different PR?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] murblanc commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

murblanc commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464108501



##
File path: 
solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestContentStreamDataSource.java
##
@@ -120,7 +120,7 @@ public void testCommitWithin() throws Exception {
 File dataDir;
 
 /**
- * if masterPort is null, this instance is a master -- otherwise this 
instance is a slave, and assumes the master is
+ * if masterPort is null, this instance is a master -- otherwise this 
instance is a secondary, and assumes the master is

Review comment:
   missed "master" references in comment (3)





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#issuecomment-667706581







This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
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

[GitHub] [lucene-solr] MarcusSorealheis commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464098026



##
File path: solr/core/src/java/org/apache/solr/util/hll/HLL.java
##
@@ -47,7 +47,7 @@
  *   https://github.com/aggregateknowledge/postgresql-hll;>postgresql-hll, 
and
  *   https://github.com/aggregateknowledge/js-hll;>js-hll
  * 
- * when https://github.com/aggregateknowledge/postgresql-hll/blob/master/STORAGE.markdown;>properly
 serialized.
+ * when https://github.com/aggregateknowledge/postgresql-hll/blob/secondaryy/STORAGE.markdown;>properly
 serialized.

Review comment:
   is a typo. good catch sorry.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
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

[Erick Erickson (Jira)]

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

Erick Erickson commented on SOLR-14702:
---

Personally I like leader/follower, I've been using those terms for years in 
SolrCloud to disambiguate the number of replicas for a shard. Does "this shard 
has 5 replicas" mean there are 5 plus a leader or is one of those 5 the leader? 
"this shard has 1 leader and 4 followers" is clear that there are exactly 5.

As far as the repo is concerned, "trunk" rather than "master" works for me. IDK 
how to rename it though. On that topic, IDK whether Mark Miller's 
reference_impl is going to resolve, but it might be a good time to change when 
that is incorporated.



> 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: 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 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)

-
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)

[Erick Erickson (Jira)]

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

Erick Erickson commented on SOLR-14701:
---

This was one of those "Elasticsearch is much easier to get started with because 
defining the schema isn't a barrier to entry" kinds of things. I've never 
particularly liked it for the reasons you outline.

The point is though that you can index docs right OOB without having to define 
a schema. True, the search is crappy. True, eventually you have to get into 
tweaking the schema, true, true, true but it's easy to start.

So I wonder how much of that ease of startup we could get if we just changed 
the default managed-schema to include:

{code}

{code}

or something like that rather than the whole schemaless approach. And if this 
works, how I wish I'd been smart enough to suggest it when schemaless was 
initially proposed, it would have saved a world of work.

> 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

[GitHub] [lucene-solr] risdenk commented on a change in pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

risdenk commented on a change in pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712#discussion_r464075185



##
File path: solr/core/src/java/org/apache/solr/util/hll/HLL.java
##
@@ -47,7 +47,7 @@
  *   https://github.com/aggregateknowledge/postgresql-hll;>postgresql-hll, 
and
  *   https://github.com/aggregateknowledge/js-hll;>js-hll
  * 
- * when https://github.com/aggregateknowledge/postgresql-hll/blob/master/STORAGE.markdown;>properly
 serialized.
+ * when https://github.com/aggregateknowledge/postgresql-hll/blob/secondaryy/STORAGE.markdown;>properly
 serialized.

Review comment:
   Is this change correct? Looks like a typo and not sure this should be 
changed?

##
File path: solr/webapp/web/js/angular/controllers/login.js
##
@@ -241,7 +241,7 @@ solrAdminApp.controller('LoginController',
 };
   }]);
 
-// This function is copied and adapted from MIT-licensed 
https://github.com/randymized/www-authenticate/blob/master/lib/parsers.js
+// This function is copied and adapted from MIT-licensed 
https://github.com/randymized/www-authenticate/blob/primary/lib/parsers.js

Review comment:
   Not sure this change should be made. Looks like a GitHub repo url





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.

[Mark Robert Miller (Jira)]

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

Mark Robert Miller commented on SOLR-14636:
---

There is not enough fun that goes on in development anymore. Robert and I used 
to have that nailed.

 !solr-ref-branch.gif!

> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
>  Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg, jenkins.png, solr-ref-branch.gif
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly 
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
>  * *core*: {color:#00875a}*extremely stable*{color} with 
> *{color:#de350b}ignores{color}*
>  * *solrj*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
>  * *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
>  * *contrib/analysis-extras*: *extremely stable* with 
> {color:#de350b}*ignores*{color}
>  * *contrib/analytics*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
>  * *contrib/clustering*: {color:#00875a}*extremely stable*{color} with 
> *{color:#de350b}ignores{color}*
>  * *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
>  * *contrib/dataimporthandler-extras*: {color:#00875a}*extremely 
> stable*{color} with *{color:#de350b}ignores{color}*
>  * *contrib/extraction*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
>  * *contrib/jaegertracer-configurator*: {color:#00875a}*extremely 
> stable*{color} with {color:#de350b}*ignores*{color}
>  * *contrib/langid*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
>  * *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color} 
> with {color:#de350b}*ignores*{color}
>  * *contrib/velocity*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more 
> frequently find bugs and requires a period of hardening._
>  _** Non Nightly currently, Nightly comes last._



--
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-14636) Provide a reference implementation for SolrCloud that is stable and fast.

[Mark Robert Miller (Jira)]

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

Mark Robert Miller updated SOLR-14636:
--
Attachment: solr-ref-branch.gif

> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
>  Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg, jenkins.png, solr-ref-branch.gif
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly 
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
>  * *core*: {color:#00875a}*extremely stable*{color} with 
> *{color:#de350b}ignores{color}*
>  * *solrj*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
>  * *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
>  * *contrib/analysis-extras*: *extremely stable* with 
> {color:#de350b}*ignores*{color}
>  * *contrib/analytics*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
>  * *contrib/clustering*: {color:#00875a}*extremely stable*{color} with 
> *{color:#de350b}ignores{color}*
>  * *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
>  * *contrib/dataimporthandler-extras*: {color:#00875a}*extremely 
> stable*{color} with *{color:#de350b}ignores{color}*
>  * *contrib/extraction*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
>  * *contrib/jaegertracer-configurator*: {color:#00875a}*extremely 
> stable*{color} with {color:#de350b}*ignores*{color}
>  * *contrib/langid*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
>  * *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color} 
> with {color:#de350b}*ignores*{color}
>  * *contrib/velocity*: {color:#00875a}*extremely stable*{color} with 
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more 
> frequently find bugs and requires a period of hardening._
>  _** Non Nightly currently, Nightly comes last._



--
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

[GitHub] [lucene-solr] MarcusSorealheis opened a new pull request #1712: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis opened a new pull request #1712:
URL: https://github.com/apache/lucene-solr/pull/1712


   …iet.
   
   
   
   
   # Description
   
   This PR removes all references of "master slave" from the Solr code base. 
this should've happened years ago as it can result in alienating many people 
working with the project.
   
   # Solution
   
   Replaces master with leader and slave with follower.
   
   # Tests
   
   Run standard tests.
   
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ ] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [ ] I have developed this patch against the `master` branch.
   - [ ] I have run `ant precommit` and the appropriate test suite.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis closed pull request #1711: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis closed pull request #1711:
URL: https://github.com/apache/lucene-solr/pull/1711


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis opened a new pull request #1711: SOLR-14702: Remove oppressive language (part1)

[GitBox]

MarcusSorealheis opened a new pull request #1711:
URL: https://github.com/apache/lucene-solr/pull/1711


   
   
   
   # Description
   
   This PR removes all references of "master slave" from the Solr code base. 
this should've happened years ago as it can result in alienating many people 
working with the project.
   
   # Solution
   
   Replaces master with leader and slave with follower.
   
   # Tests
   
   Run standard tests.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ ] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [ ] I have developed this patch against the `master` branch.
   - [ ] I have run `ant precommit` and the appropriate test suite.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis commented on pull request #1710: SOLR-14604: Uninstall package cli command

[GitBox]

MarcusSorealheis commented on pull request #1710:
URL: https://github.com/apache/lucene-solr/pull/1710#issuecomment-667648035


   I don't know why all these commits show up. Maybe it's because I started 
this a while ago and then got pulled in different direction and had to merge 
over and over to catch up over time. I can re-open if necessary but should be 
no conflicts with master @chatman @noblepaul @madrob if one of you guys get a 
moment. This the follow up and loop closing on my previous plus a tiny bit of 
cleanup for clarity. I think y'all can expect more work from me on these areas 
because they are important to my work. 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis closed pull request #1710: SOLR-14604: Uninstall package cli command

[GitBox]

MarcusSorealheis closed pull request #1710:
URL: https://github.com/apache/lucene-solr/pull/1710


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [lucene-solr] MarcusSorealheis opened a new pull request #1710: SOLR-14604: Uninstall package cli command

[GitBox]

MarcusSorealheis opened a new pull request #1710:
URL: https://github.com/apache/lucene-solr/pull/1710


   
   
   
   # Description
   
   Developers should be able to uninstall a package they upload via the package 
management system. If a package becomes vulnerable, it's code should be 
completely removable from the system, for instance. 
   
   # Solution
   
   Add a CLI command to delete a package.
   
   # Tests
   
   Requires manual integration test.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ ] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [ ] I have developed this patch against the `master` branch.
   - [ ] I have run `ant precommit` and the appropriate test suite.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
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 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] [Commented] (SOLR-14701) Deprecate Schemaless Mode (Discussion)

[Ishan Chattopadhyaya (Jira)]

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

Ishan Chattopadhyaya commented on SOLR-14701:
-

+1, this is the default experience today and is totally broken. We should 
either fix it or remove it. BTW, we need to revive SOLR-11741.
Thanks for starting this discussion Marcus. Even though dev@ list may have been 
a better place, but now that this issue exists, we should document some 
examples where schemaless is broken and confuses users.

> 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] [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