[jira] [Commented] (LUCENE-10471) Increase the number of dims for KNN vectors to 2048
[ https://issues.apache.org/jira/browse/LUCENE-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17577849#comment-17577849 ] Marcus Eagan commented on LUCENE-10471: --- [~michi] You are free to increase the dimension limit as it is a static variable and Lucene is your oyster. However, [~ehatcher] has Seared in my mind that this a long term fork ok Lucene is a bad idea for many reasons. #[~rcmuir] I agree with you on "whatever shitty models." They are here, and more are coming. With respect to the vector API, Oracle is doing an interesting bit of work in Open JDK 17 to improve their vector API. They've added support for Intel's short vector math library, which will improve. The folk at OpenJDK exploit the Panama APIs. There are several hardware accelerations they are yet to exploit, and many operations will fall back to scalar code. My argument is for increasing the limit of dimensions is not to suggest that there is a better fulcrum in the performance tradeoff balancer, but that more users testing Lucene is good for improving the feature. Open AI's Da Vinci is one such model but not the only I've had customers ask for 4096 based on the performance they observe with question an answering. I'm waiting on the model and will share when I know. If customers want to introduce rampant numerical errors in their systems, there is little we can do for them. Don't take my word on any of this yet. I need to bring data and complete evidence. I'm asking my customers why they cannot do dimensional reduction. > Increase the number of dims for KNN vectors to 2048 > --- > > Key: LUCENE-10471 > URL: https://issues.apache.org/jira/browse/LUCENE-10471 > Project: Lucene - Core > Issue Type: Wish >Reporter: Mayya Sharipova >Priority: Trivial > Time Spent: 40m > Remaining Estimate: 0h > > The current maximum allowed number of dimensions is equal to 1024. But we see > in practice a couple well-known models that produce vectors with > 1024 > dimensions (e.g > [mobilenet_v2|https://tfhub.dev/google/imagenet/mobilenet_v2_035_224/feature_vector/1] > uses 1280d vectors, OpenAI / GPT-3 Babbage uses 2048d vectors). Increasing > max dims to `2048` will satisfy these use cases. > I am wondering if anybody has strong objections against this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8637) WeightedSpanTermExtractor unnexessarily enforces rewrite for some SpanQueiries
[ https://issues.apache.org/jira/browse/LUCENE-8637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17426406#comment-17426406 ] Marcus Eagan commented on LUCENE-8637: -- [~gol...@detego-software.de] Can you check if it breaks unit tests? Do you know how to run the whole suite? > WeightedSpanTermExtractor unnexessarily enforces rewrite for some SpanQueiries > -- > > Key: LUCENE-8637 > URL: https://issues.apache.org/jira/browse/LUCENE-8637 > Project: Lucene - Core > Issue Type: Bug > Components: modules/highlighter >Affects Versions: 7.4, 7.3.1, 7.5, 7.6 >Reporter: Christoph Goller >Priority: Minor > Labels: patch > Attachments: WeightedSpanTermExtractor.java > > > Method mustRewriteQuery(SpanQuery) returns true for SpanPositionCheckQuery, > SpanContainingQuery, SpanWithinQuery, and SpanBoostQuery, however, these > queries do not require rewriting. One effect of this is e.g. that > UnifiedHighlighter does not work with OffsetSource Postings and switches to > Analysis which of course has consequences for performance. > I attach a patch for lucene version 7.6.0. I have not checked whether it > breaks existing unit tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7321) Character Mapping
[ https://issues.apache.org/jira/browse/LUCENE-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17356136#comment-17356136 ] Marcus Eagan commented on LUCENE-7321: -- Hi [~iprovalo] I'm curious if you have been maintaining this patch through version `8` for your company? If so, do you want to revive this discussion? > Character Mapping > - > > Key: LUCENE-7321 > URL: https://issues.apache.org/jira/browse/LUCENE-7321 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.6.1, 5.4.1, 6.0, 6.0.1 >Reporter: Ivan Provalov >Priority: Minor > Labels: patch > Fix For: 6.0.1 > > Attachments: CharacterMappingComponent.pdf, LUCENE-7321.patch > > > One of the challenges in search is recall of an item with a common typing > variant. These cases can be as simple as lower/upper case in most languages, > accented characters, or more complex morphological phenomena like prefix > omitting, or constructing a character with some combining mark. This > component addresses the cases, which are not covered by ASCII folding > component, or more complex to design with other tools. The idea is that a > linguist could provide the mappings in a tab-delimited file, which then can > be directly used by Solr. > The mappings are maintained in the tab-delimited file, which could be just a > copy paste from Excel spreadsheet. This gives the linguists the opportunity > to create the mappings, then for the developer to include them in Solr > configuration. There are a few cases, when the mappings grow complex, where > some additional debugging may be required. The mappings can contain any > sequence of characters to any other sequence of characters. > Some of the cases I discuss in detail document are handling the voiced vowels > for Japanese; common typing substitutions for Korean, Russian, Polish; > transliteration for Polish, Arabic; prefix removal for Arabic; suffix folding > for Japanese. In the appendix, I give an example of implementing a Russian > light weight stemmer using this component. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8626) standardise test class naming
[ https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17297815#comment-17297815 ] Marcus Eagan commented on LUCENE-8626: -- Thank you Christine for wrapping this up. Looks like it was open for 859d 47m. > standardise test class naming > - > > Key: LUCENE-8626 > URL: https://issues.apache.org/jira/browse/LUCENE-8626 > Project: Lucene - Core > Issue Type: Test >Reporter: Christine Poerschke >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, > SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch > > Time Spent: 4h 40m > Remaining Estimate: 0h > > This was mentioned and proposed on the dev mailing list. Starting this ticket > here to start to make it happen? > History: This ticket was created as > https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got > JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15158) Error when upgrading from Solr 8.0.0 to 8.5.2
[ https://issues.apache.org/jira/browse/SOLR-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17297016#comment-17297016 ] Marcus Eagan commented on SOLR-15158: - Hi [~amitguptag] I suspect this issue could be caused by a variety of factors. One that comes to mind immediately is improper formatting of a config file, likely JSON because of the comma and AUTHORIZATION being called out in the error message. Can you double check the integrity of your security.json file? Ensure it is formatted appropriately. Furthermore, there were a few significant changes from 8 to 8.5. I would start there, though. > Error when upgrading from Solr 8.0.0 to 8.5.2 > - > > Key: SOLR-15158 > URL: https://issues.apache.org/jira/browse/SOLR-15158 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 8.5.2 >Reporter: Amit Gupta >Priority: Blocker > Labels: 8.5.2, solr, upgrade > > I am trying to upgrade our tech stack from 8.0.0 to 8.5.2. The cofiguration > work until the first time the ersver is rebooted. Then solr stops working > with below error. The exact same config works with solr 8.0.0 without issues. > Extract from solr.log: > 021-02-15 19:04:52.922 INFO (main) [ ] o.a.s.c.ZkContainer Zookeeper > client=10.201.52.56:2181,10.201.52.169:2181,10.201.52.136:2181 > 2021-02-15 19:04:52.940 INFO (main) [ ] o.a.s.c.c.ConnectionManager Waiting > for client to connect to ZooKeeper > 2021-02-15 19:04:52.949 INFO (zkConnectionManagerCallback-9-thread-1) [ ] > o.a.s.c.c.ConnectionManager zkClient has connected > 2021-02-15 19:04:52.949 INFO (main) [ ] o.a.s.c.c.ConnectionManager Client is > connected to ZooKeeper > 2021-02-15 19:04:53.047 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could not > start Solr. Check solr/home property and the logs > 2021-02-15 19:04:53.077 ERROR (main) [ ] o.a.s.c.SolrCore > null:org.noggit.JSONParser$ParseException: Unexpected comma: > char=,,position=324 AFTER='QuEFwT7s= > nlE/oRd/BIthqBP8UY1yFiu6Betb7xDoyTPFD3AxaUo="}} },' BEFORE=' > "authorization":{ "class":"solr.R' > at org.noggit.JSONParser.err(JSONParser.java:452) > at org.noggit.JSONParser.next(JSONParser.java:1013) > at org.noggit.JSONParser.nextEvent(JSONParser.java:1073) > at org.noggit.ObjectBuilder.checkEOF(ObjectBuilder.java:52) > at org.noggit.ObjectBuilder.getValStrict(ObjectBuilder.java:76) > at org.apache.solr.common.util.Utils.fromJSON(Utils.java:270) > at org.apache.solr.common.util.Utils.fromJSON(Utils.java:256) > at > org.apache.solr.common.cloud.ZkStateReader.getSecurityProps(ZkStateReader.java:1274) > at > org.apache.solr.common.cloud.ZkStateReader.createClusterStateWatchersAndUpdate(ZkStateReader.java:527) > at org.apache.solr.cloud.ZkController.init(ZkController.java:902) > at org.apache.solr.cloud.ZkController.(ZkController.java:472) > at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:115) > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:663) > at > org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:263) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:183) > at org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134) > at > org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751) > at > java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734) > at > java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:658) > at > org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744) > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360) > at > org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445) > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409) > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822) > at > org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275) > at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524) > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72) > at > org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46) > at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188) > at > org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513) > at > org.eclipse.jetty.deploy.DeploymentManager.addApp(Deplo
[jira] [Commented] (LUCENE-9431) UnifiedHighlighter: Make WEIGHT_MATCHES the default
[ https://issues.apache.org/jira/browse/LUCENE-9431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280397#comment-17280397 ] Marcus Eagan commented on LUCENE-9431: -- Hi Yury, Are you still working on this ticket? > UnifiedHighlighter: Make WEIGHT_MATCHES the default > --- > > Key: LUCENE-9431 > URL: https://issues.apache.org/jira/browse/LUCENE-9431 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Reporter: David Smiley >Priority: Blocker > Fix For: master (9.0) > > > This mode uses Lucene's modern mechanism of exposing information that > previously required complicated highlighting machinery. It's also likely to > generally work better out-of-the-box and with custom queries. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-14702: Description: Every time I read _master_ and _slave_, I get pissed. I think about the last and only time I remember visiting my maternal great grandpa in Alabama at four years old. He was a sharecropper before WWI, where he lost his legs, and then he was back to being a sharecropper somehow after the war. Crazy, I know. I don't know if the world still called his job sharecropping in 1993, but he was basically a slave—in America. He lived in the same shack that his father, and his grandfather (born a slave) lived in down in Alabama. Believe it or not, my dad's grandfather was actually born a slave, freed shortly after birth by his owner father. I never met him, though. He died in the 40s. Anyway, I cannot police all terms in the repo and do not wish to. This master/slave shit is archaic and misleading on technical grounds. Thankfully, there's only a handful of files in code and documentation that still talk about masters and slaves. We should replace all of them. There are so many ways to reword it. In fact, unless anyone else objects or wants to do the grunt work to help my stress levels, I will open the pull request myself in effort to make this project and community more inviting to people of all backgrounds and histories. We can have leader/follower, or primary/secondary, but none of this Master/Slave nonsense. I'm sick of the garbage. was: Every time I read _master_ and _slave_, I get pissed. I think about the last and only time I remember visiting my maternal great grandpa in Alabama at four years old. He was a sharecropper before WWI, where he lost his legs, and then he was back to being a sharecropper somehow after the war. Crazy, I know. I don't know if the world still called his job sharecropping in 1993, but he was basically a slave—in America. He lived in the same shack that his father, and his grandfather (born a slave) lived in down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was actually born a slave, freed shortly after birth by his owner father. I never met him, though. He died in the 40s. Anyway, I cannot police all terms in the repo and do not wish to. This master/slave shit is archaic and misleading on technical grounds. Thankfully, there's only a handful of files in code and documentation that still talk about masters and slaves. We should replace all of them. There are so many ways to reword it. In fact, unless anyone else objects or wants to do the grunt work to help my stress levels, I will open the pull request myself in effort to make this project and community more inviting to people of all backgrounds and histories. We can have leader/follower, or primary/secondary, but none of this Master/Slave nonsense. I'm sick of the garbage. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Fix For: 8.7, master (9.0) > > Attachments: SOLR-14742-testfix.patch > > Time Spent: 17h > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's grandfather was actually born a > slave, freed shortly after birth by his owner father. I never met him, > though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) ---
[jira] [Commented] (LUCENE-8626) standardise test class naming
[ https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17268864#comment-17268864 ] Marcus Eagan commented on LUCENE-8626: -- I've added the final batch of standardized tests. No more inconsistencies. https://github.com/apache/lucene-solr/pull/2220 > standardise test class naming > - > > Key: LUCENE-8626 > URL: https://issues.apache.org/jira/browse/LUCENE-8626 > Project: Lucene - Core > Issue Type: Test >Reporter: Christine Poerschke >Priority: Major > Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, > SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > This was mentioned and proposed on the dev mailing list. Starting this ticket > here to start to make it happen? > History: This ticket was created as > https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got > JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8626) standardise test class naming
[ https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224350#comment-17224350 ] Marcus Eagan commented on LUCENE-8626: -- [I added another 36 tests to this ticket|https://github.com/apache/lucene-solr/pull/2053] > standardise test class naming > - > > Key: LUCENE-8626 > URL: https://issues.apache.org/jira/browse/LUCENE-8626 > Project: Lucene - Core > Issue Type: Test >Reporter: Christine Poerschke >Priority: Major > Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, > SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch > > Time Spent: 2.5h > Remaining Estimate: 0h > > This was mentioned and proposed on the dev mailing list. Starting this ticket > here to start to make it happen? > History: This ticket was created as > https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got > JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14708) Backward-Compatible Replication
[ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211773#comment-17211773 ] Marcus Eagan commented on SOLR-14708: - That’s right, users may experience issues with the cache. Maybe we should be explicit about cache as the potential cause of issues? > Backward-Compatible Replication > --- > > Key: SOLR-14708 > URL: https://issues.apache.org/jira/browse/SOLR-14708 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Marcus Eagan >Priority: Critical > > In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed > that we remove master/slave terminology from the Solr codebase. Now that's > complete, we need to ensure it is backward compatible to support rolling > upgrades from 8.7.x to 9.x because we really ought not to make it harder to > upgrade Solr. > Tomas offered a helpful path in a now abandoned PR: > {quote}One way to get back compatibility and rolling upgrades could be to > make 9.x code be able to read previous formats, but write new format, and > make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a > rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to > 8.7 would still work. > All the code other than the requests/responses could be changed in 8_x > branch, in addition to master. > {quote} > The approach that we will take is to add a ternary operator in 9_X to accept > parameter values for the legacy verbiage, or leader/follower, but only write > leader/follower. We need to then make 8_x work in the inverse way. The burden > here is not on that proposal or on the code in my view. Instead, the burden > is on the test plan. > If anyone has any guidance please share but here are my thoughts: > Case A: > Test the case where a user is running a standalone cluster in 8 with three > nodes but then updates one of the nodes. > Case B: > Test the case where a user is running a mixed cluster standalone cluster, and > the leader node is forced to fail and then is brought back. > Case C: > A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a > rolling upgrade and a follower needs to become leader. > I know haven't listed all possible scenarios or everything that could happen. > Please let me know if you have thoughts or guidance on how best to accomplish > this work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14777) Chipping Away at Test Ignore in the Reference Impl Part 1
Marcus Eagan created SOLR-14777: --- Summary: Chipping Away at Test Ignore in the Reference Impl Part 1 Key: SOLR-14777 URL: https://issues.apache.org/jira/browse/SOLR-14777 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: master (9.0) Reporter: Marcus Eagan I want to contribute to the future of Lucene and Solr :)! For me, one action would be to help advance [~markrmil...@gmail.com]'s Reference Implementation with the dirty work we all hate doing. Hopefully, I'll open up a few PRs against his branch that improve test coverage. I'll keep my commits and my PRs atomic to facilitate quicker review because I know we are all busy and need to be able to understand what's happening quickly. I want to be a leader in this community one day and it is incumbent on those who aspire to be leaders to do the things that no one else uninspired (and probably more talented) would want to do first. Wish me luck and stay tuned! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14726) Streamline getting started experience
[ https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182825#comment-17182825 ] Marcus Eagan commented on SOLR-14726: - [~arafalov] Whatever committer(s) own the getting developer experience for developers should seriously consider taking ownership of this problem. V2 implies that the community should use it soon if not now. As someone who is regularly using the project, it is confusing even for me. Who is that person, or who are those people? > Streamline getting started experience > - > > Key: SOLR-14726 > URL: https://issues.apache.org/jira/browse/SOLR-14726 > Project: Solr > Issue Type: Task >Reporter: Ishan Chattopadhyaya >Priority: Major > Labels: newdev > Attachments: yasa-http.png > > > The reference guide Solr tutorial is here: > https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html > It needs to be simplified and easy to follow. Also, it should reflect our > best practices, that should also be followed in production. I have following > suggestions: > # Make it less verbose. It is too long. On my laptop, it required 35 page > downs button presses to get to the bottom of the page! > # First step of the tutorial should be to enable security (basic auth should > suffice). > # {{./bin/solr start -e cloud}} <-- All references of -e should be removed. > # All references of {{bin/solr post}} to be replaced with {{curl}} > # Convert all {{bin/solr create}} references to curl of collection creation > commands > # Add docker based startup instructions. > # Create a Jupyter Notebook version of the entire tutorial, make it so that > it can be easily executed from Google Colaboratory. Here's an example: > https://twitter.com/TheSearchStack/status/1289703715981496320 > # Provide downloadable Postman and Insomnia files so that the same tutorial > can be executed from those tools. Except for starting Solr, all other steps > should be possible to be carried out from those tools. > # Use V2 APIs everywhere in the tutorial > # Remove all example modes, sample data (films, tech products etc.), > configsets from Solr's distribution (instead let the examples refer to them > from github) > # Remove the post tool from Solr, curl should suffice. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14726) Streamline getting started experience
[ https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182825#comment-17182825 ] Marcus Eagan edited comment on SOLR-14726 at 8/23/20, 7:01 PM: --- [~arafalov] Whichever committer(s) own the getting developer experience for developers should seriously consider taking ownership of this problem. V2 implies that the community should use it soon if not now. As someone who is regularly using the project, it is confusing even for me. Who is that person, or who are those people? was (Author: marcussorealheis): [~arafalov] Whatever committer(s) own the getting developer experience for developers should seriously consider taking ownership of this problem. V2 implies that the community should use it soon if not now. As someone who is regularly using the project, it is confusing even for me. Who is that person, or who are those people? > Streamline getting started experience > - > > Key: SOLR-14726 > URL: https://issues.apache.org/jira/browse/SOLR-14726 > Project: Solr > Issue Type: Task >Reporter: Ishan Chattopadhyaya >Priority: Major > Labels: newdev > Attachments: yasa-http.png > > > The reference guide Solr tutorial is here: > https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html > It needs to be simplified and easy to follow. Also, it should reflect our > best practices, that should also be followed in production. I have following > suggestions: > # Make it less verbose. It is too long. On my laptop, it required 35 page > downs button presses to get to the bottom of the page! > # First step of the tutorial should be to enable security (basic auth should > suffice). > # {{./bin/solr start -e cloud}} <-- All references of -e should be removed. > # All references of {{bin/solr post}} to be replaced with {{curl}} > # Convert all {{bin/solr create}} references to curl of collection creation > commands > # Add docker based startup instructions. > # Create a Jupyter Notebook version of the entire tutorial, make it so that > it can be easily executed from Google Colaboratory. Here's an example: > https://twitter.com/TheSearchStack/status/1289703715981496320 > # Provide downloadable Postman and Insomnia files so that the same tutorial > can be executed from those tools. Except for starting Solr, all other steps > should be possible to be carried out from those tools. > # Use V2 APIs everywhere in the tutorial > # Remove all example modes, sample data (films, tech products etc.), > configsets from Solr's distribution (instead let the examples refer to them > from github) > # Remove the post tool from Solr, curl should suffice. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14705) Release Smoke Test Script Shows Unusable JDK Version
[ https://issues.apache.org/jira/browse/SOLR-14705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182044#comment-17182044 ] Marcus Eagan commented on SOLR-14705: - Agree > Release Smoke Test Script Shows Unusable JDK Version > > > Key: SOLR-14705 > URL: https://issues.apache.org/jira/browse/SOLR-14705 > Project: Solr > Issue Type: Bug > Components: release-scripts >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Minor > > The script works fine, but the help text in the smoke test script needs to be > replaced. Should be Java 8 for now and moved to Java 11 when the community is > preparing to release Solr 9. :) > Here's the output: > usage: smokeTestRelease.py [-h] [--tmp-dir PATH] [--not-signed] >[--local-keys PATH] [--revision REVISION] >[--version X.Y.Z(-ALPHA|-BETA)?] >[--test-java9 JAVA9_HOME] [--download-only] >url ... > > I wouldn't touch Java 9 with a ten foot pole, and nor should new releases. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14753) More Consistent Thread Safety Annotations.
[ https://issues.apache.org/jira/browse/SOLR-14753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178093#comment-17178093 ] Marcus Eagan commented on SOLR-14753: - [~anshum] Can you take a look and merge this PR. It's very simple. > More Consistent Thread Safety Annotations. > -- > > Key: SOLR-14753 > URL: https://issues.apache.org/jira/browse/SOLR-14753 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This is a simple but important step to adopt more consistent thread safety > annotations originally created by Mark Miller and added into Solr by Anshum > from an internal Apple fork. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14731) Make use of @SolrSingleThreaded Implementation
[ https://issues.apache.org/jira/browse/SOLR-14731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178092#comment-17178092 ] Marcus Eagan commented on SOLR-14731: - This PR makes use of an improved name, but will cause pre-commit to fail until it succeeds. > Make use of @SolrSingleThreaded Implementation > --- > > Key: SOLR-14731 > URL: https://issues.apache.org/jira/browse/SOLR-14731 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Environment: {color:red}colored text{color} >Reporter: Marcus Eagan >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > This change may viewed as minor today, but making a habit of this annotation > should prove very beneficial in the long run when I forget things that I > worked on 3 years ago, 3 years from now. > This is my first attempt to leverage [~anshum]'s work from: > https://issues.apache.org/jira/browse/SOLR-13998 > [~anshum] please let me know if I am screwing something up! :) and thanks for > adding this a while back. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14753) More Consistent Thread Safety Annotations.
Marcus Eagan created SOLR-14753: --- Summary: More Consistent Thread Safety Annotations. Key: SOLR-14753 URL: https://issues.apache.org/jira/browse/SOLR-14753 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: master (9.0) Reporter: Marcus Eagan This is a simple but important step to adopt more consistent thread safety annotations originally created by Mark Miller and added into Solr by Anshum from an internal Apple fork. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178079#comment-17178079 ] Marcus Eagan commented on SOLR-13998: - Great. Thanks [~cpoerschke] and [~dsmiley]. > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14731) Make use of @SolrSingleThreaded Implementation
[ https://issues.apache.org/jira/browse/SOLR-14731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176145#comment-17176145 ] Marcus Eagan commented on SOLR-14731: - this is an annotation to denote that this class is single-threaded. > Make use of @SolrSingleThreaded Implementation > --- > > Key: SOLR-14731 > URL: https://issues.apache.org/jira/browse/SOLR-14731 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Environment: {color:red}colored text{color} >Reporter: Marcus Eagan >Priority: Major > > This change may viewed as minor today, but making a habit of this annotation > should prove very beneficial in the long run when I forget things that I > worked on 3 years ago, 3 years from now. > This is my first attempt to leverage [~anshum]'s work from: > https://issues.apache.org/jira/browse/SOLR-13998 > [~anshum] please let me know if I am screwing something up! :) and thanks for > adding this a while back. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14731) Make use of @SolrSingleThreaded Implementation
Marcus Eagan created SOLR-14731: --- Summary: Make use of @SolrSingleThreaded Implementation Key: SOLR-14731 URL: https://issues.apache.org/jira/browse/SOLR-14731 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Environment: {color:red}colored text{color} Reporter: Marcus Eagan This change may viewed as minor today, but making a habit of this annotation should prove very beneficial in the long run when I forget things that I worked on 3 years ago, 3 years from now. This is my first attempt to leverage [~anshum]'s work from: https://issues.apache.org/jira/browse/SOLR-13998 [~anshum] please let me know if I am screwing something up! :) and thanks for adding this a while back. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176101#comment-17176101 ] Marcus Eagan commented on SOLR-13998: - [~anshum] that makes sense. I didn't realized it was cherry picked from his branch. Adding that context into the PR comments before merging might help people to understand the rationale and give them a place to look to contribute. I'll be sure to add it in future classes because I have recently written a single threaded class. If I knew about this, I would have used it. In any event, I am happy it's there if it useful for others. > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176102#comment-17176102 ] Marcus Eagan commented on SOLR-13998: - [~anshum] can you link to the branch Mark shared? > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8626) standardise test class naming
[ https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176068#comment-17176068 ] Marcus Eagan commented on LUCENE-8626: -- Great ideas [~dweiss] and [~dsmiley]! > standardise test class naming > - > > Key: LUCENE-8626 > URL: https://issues.apache.org/jira/browse/LUCENE-8626 > Project: Lucene - Core > Issue Type: Test >Reporter: Christine Poerschke >Priority: Major > Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, > SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch > > > This was mentioned and proposed on the dev mailing list. Starting this ticket > here to start to make it happen? > History: This ticket was created as > https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got > JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13998) Add thread safety annotation to classes
[ https://issues.apache.org/jira/browse/SOLR-13998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176031#comment-17176031 ] Marcus Eagan commented on SOLR-13998: - Hi [~anshum] I'm working on some janitorial work in the project, and I noticed that you added annotations, but did not implement them. Thus, this title is misleading, and one of the annotations added here has only been used once since you added this PR in December. I'm curious what you had in mind for the SolrSingleThreaded annotation and why didn't you actually add the annotation anywhere. Futhermore, would you like help to expand the usage of this class, or do you feel it was hastily added and is a waste of time? I doubt the latter because there should be quite a few obvious uses for this code. However, I will defer to you since you added it. I'm looking through all the PRs of this year to create an inventory of the sort of code and behavior (in code) that I'd hope to steward the community away from. I have a few items so far, but this is one I was not totally sure about because of its sparsity and how long it had been just sitting in the repo (7 months before any usage at all). I also don't know if the way Solr operates is, we just throw tools into the toolbox and if someone uses them one day, great. If not, someone will one day. Ideally, if we bring something to the project we ourselves would at least use it because we see value in it. I'm an outsider, learning everyday, and hoping to improve the project. > Add thread safety annotation to classes > --- > > Key: SOLR-13998 > URL: https://issues.apache.org/jira/browse/SOLR-13998 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Fix For: master (9.0), 8.4 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add annotations that can be used to mark classes as thread safe / single > threaded in Solr. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14726) Streamline getting started experience
[ https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17174436#comment-17174436 ] Marcus Eagan commented on SOLR-14726: - bq. My experience from delivering the Solr version of Think Like a Relevance Engineer is that MANY MANY people aren't able to install python. They may be on Windows, they may not have "Developer" permissions, they may have Python 2 versus 3, or it's just not something they use at all. Yeah, if you're not a Python engineer I have watched very skilled engineers struggle with Python and understanding pip and virtual environments. I would vote absolutely against adding Python even though it is my favorite and strongest language by far. > Streamline getting started experience > - > > Key: SOLR-14726 > URL: https://issues.apache.org/jira/browse/SOLR-14726 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Labels: newdev > > The reference guide Solr tutorial is here: > https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html > It needs to be simplified and easy to follow. Also, it should reflect our > best practices, that should also be followed in production. I have following > suggestions: > # Make it less verbose. It is too long. On my laptop, it required 35 page > downs button presses to get to the bottom of the page! > # First step of the tutorial should be to enable security (basic auth should > suffice). > # {{./bin/solr start -e cloud}} <-- All references of -e should be removed. > # All references of {{bin/solr post}} to be replaced with {{curl}} > # Convert all {{bin/solr create}} references to curl of collection creation > commands > # Add docker based startup instructions. > # Create a Jupyter Notebook version of the entire tutorial, make it so that > it can be easily executed from Google Colaboratory. Here's an example: > https://twitter.com/TheSearchStack/status/1289703715981496320 > # Provide downloadable Postman and Insomnia files so that the same tutorial > can be executed from those tools. Except for starting Solr, all other steps > should be possible to be carried out from those tools. > # Use V2 APIs everywhere in the tutorial > # Remove all example modes, sample data (films, tech products etc.), > configsets from Solr's distribution (instead let the examples refer to them > from github) > # Remove the post tool from Solr, curl should suffice. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14726) Streamline getting started experience
[ https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17174434#comment-17174434 ] Marcus Eagan commented on SOLR-14726: - bq. If we could rely on Python and felt free to ask people to install things, I would lean towards HTTPie instead of curl: https://httpie.org/ HTTPie is amazing but still fringe in terms of adoption. Everyone knows cURL. I think that we should be able to point people to public datasets that are hosted elsewhere (maybe by one of us) rather than shipping Solr with example data. I'm happy to donate a public data repository for 10 years. > Streamline getting started experience > - > > Key: SOLR-14726 > URL: https://issues.apache.org/jira/browse/SOLR-14726 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Labels: newdev > > The reference guide Solr tutorial is here: > https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html > It needs to be simplified and easy to follow. Also, it should reflect our > best practices, that should also be followed in production. I have following > suggestions: > # Make it less verbose. It is too long. On my laptop, it required 35 page > downs button presses to get to the bottom of the page! > # First step of the tutorial should be to enable security (basic auth should > suffice). > # {{./bin/solr start -e cloud}} <-- All references of -e should be removed. > # All references of {{bin/solr post}} to be replaced with {{curl}} > # Convert all {{bin/solr create}} references to curl of collection creation > commands > # Add docker based startup instructions. > # Create a Jupyter Notebook version of the entire tutorial, make it so that > it can be easily executed from Google Colaboratory. Here's an example: > https://twitter.com/TheSearchStack/status/1289703715981496320 > # Provide downloadable Postman and Insomnia files so that the same tutorial > can be executed from those tools. Except for starting Solr, all other steps > should be possible to be carried out from those tools. > # Use V2 APIs everywhere in the tutorial > # Remove all example modes, sample data (films, tech products etc.), > configsets from Solr's distribution (instead let the examples refer to them > from github) > # Remove the post tool from Solr, curl should suffice. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14726) Streamline getting started experience
[ https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173965#comment-17173965 ] Marcus Eagan commented on SOLR-14726: - I also think a video from someone in the community should be made. Some people learn differently. > Streamline getting started experience > - > > Key: SOLR-14726 > URL: https://issues.apache.org/jira/browse/SOLR-14726 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Labels: newdev > > The reference guide Solr tutorial is here: > https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html > It needs to be simplified and easy to follow. Also, it should reflect our > best practices, that should also be followed in production. I have following > suggestions: > # Make it less verbose. It is too long. On my laptop, it required 35 page > downs button presses to get to the bottom of the page! > # First step of the tutorial should be to enable security (basic auth should > suffice). > # {{./bin/solr start -e cloud}} <-- All references of -e should be removed. > # All references of {{bin/solr post}} to be replaced with {{curl}} > # Convert all {{bin/solr create}} references to curl of collection creation > commands > # Add docker based startup instructions. > # Create a Jupyter Notebook version of the entire tutorial, make it so that > it can be easily executed from Google Colaboratory. Here's an example: > https://twitter.com/TheSearchStack/status/1289703715981496320 > # Provide downloadable Postman and Insomnia files so that the same tutorial > can be executed from those tools. Except for starting Solr, all other steps > should be possible to be carried out from those tools. > # Use V2 APIs everywhere in the tutorial > # Remove all example modes, sample data (films, tech products etc.), > configsets from Solr's distribution (instead let the examples refer to them > from github) > # Remove the post tool from Solr, curl should suffice. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14726) Streamline getting started experience
[ https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-14726: Labels: newdev (was: ) > Streamline getting started experience > - > > Key: SOLR-14726 > URL: https://issues.apache.org/jira/browse/SOLR-14726 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Labels: newdev > > The reference guide Solr tutorial is here: > https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html > It needs to be simplified and easy to follow. Also, it should reflect our > best practices, that should also be followed in production. I have following > suggestions: > # Make it less verbose. It is too long. On my laptop, it required 35 page > downs button presses to get to the bottom of the page! > # First step of the tutorial should be to enable security (basic auth should > suffice). > # {{./bin/solr start -e cloud}} <-- All references of -e should be removed. > # All references of {{bin/solr post}} to be replaced with {{curl}} > # Convert all {{bin/solr create}} references to curl of collection creation > commands > # Add docker based startup instructions. > # Create a Jupyter Notebook version of the entire tutorial, make it so that > it can be easily executed from Google Colaboratory. Here's an example: > https://twitter.com/TheSearchStack/status/1289703715981496320 > # Provide downloadable Postman and Insomnia files so that the same tutorial > can be executed from those tools. Except for starting Solr, all other steps > should be possible to be carried out from those tools. > # Use V2 APIs everywhere in the tutorial > # Remove all example modes, sample data (films, tech products etc.), > configsets from Solr's distribution (instead let the examples refer to them > from github) > # Remove the post tool from Solr, curl should suffice. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13438) DELETE collection should remove AUTOCREATED configsets
[ https://issues.apache.org/jira/browse/SOLR-13438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173962#comment-17173962 ] Marcus Eagan commented on SOLR-13438: - [~ichattopadhyaya] I'll leave this issue open for a new dev to step in and get involved. If it is not fixed after a while, I will wrap it up. I personally have seen this issue cause many problems. > DELETE collection should remove AUTOCREATED configsets > -- > > Key: SOLR-13438 > URL: https://issues.apache.org/jira/browse/SOLR-13438 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Major > Labels: newdev > > Current user experience: > # User creates a collection (without specifying configset), and makes some > schema/config changes. > # He's/She's not happy with how the changes turned out, so he/she deletes and > re-creates the collection. > # He/she observes that the previously made settings changes persist. If > he/she is only aware of Schema and Config APIs and not explicitly aware of > the concept of configsets, this will be un-intuitive for him/her. > Proposed: > DELETE collection should delete the configset if it has the prefix > ".AUTOCREATED" and that configset isn't being shared by any other collection. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14726) Streamline getting started experience
[ https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173960#comment-17173960 ] Marcus Eagan commented on SOLR-14726: - Looks like a great list to start. > Streamline getting started experience > - > > Key: SOLR-14726 > URL: https://issues.apache.org/jira/browse/SOLR-14726 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > > The reference guide Solr tutorial is here: > https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html > It needs to be simplified and easy to follow. Also, it should reflect our > best practices, that should also be followed in production. I have following > suggestions: > # Make it less verbose. It is too long. > # First step of the tutorial should be to enable security (basic auth should > suffice). > # {{./bin/solr start -e cloud}} <-- All references of -e should be removed. > # All references of {{bin/solr post}} to be replaced with {{curl}} > # Convert all {{bin/solr create}} references to curl of collection creation > commands > # Add docker based startup instructions. > # Create a Jupyter Notebook version of the entire tutorial, make it so that > it can be easily executed from Google Colaboratory. Here's an example: > https://twitter.com/TheSearchStack/status/1289703715981496320 > # Provide downloadable Postman and Insomnia files so that the same tutorial > can be executed from those tools. Except for starting Solr, all other steps > should be possible to be carried out from those tools. > # Use V2 APIs everywhere in the tutorial > # Remove all example modes, sample data (films, tech products etc.), > configsets from Solr's distribution (instead let the examples refer to them > from github) > # Remove the post tool from Solr, curl should suffice. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13438) DELETE collection should remove AUTOCREATED configsets
[ https://issues.apache.org/jira/browse/SOLR-13438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173668#comment-17173668 ] Marcus Eagan commented on SOLR-13438: - [~ichattopadhyaya] It's a constant issue for many users. > DELETE collection should remove AUTOCREATED configsets > -- > > Key: SOLR-13438 > URL: https://issues.apache.org/jira/browse/SOLR-13438 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Major > Labels: newdev > > Current user experience: > # User creates a collection (without specifying configset), and makes some > schema/config changes. > # He's/She's not happy with how the changes turned out, so he/she deletes and > re-creates the collection. > # He/she observes that the previously made settings changes persist. If > he/she is only aware of Schema and Config APIs and not explicitly aware of > the concept of configsets, this will be un-intuitive for him/her. > Proposed: > DELETE collection should delete the configset if it has the prefix > ".AUTOCREATED" and that configset isn't being shared by any other collection. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14708) Backward-Compatible Replication
[ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173490#comment-17173490 ] Marcus Eagan commented on SOLR-14708: - I was able to query both nodes, but maybe my UI had some other issue. The caching issue depends on the configset, it seems. I suppose the solution will work sufficiently for the needs of the project and users will need to adjust accordingly. I'd rather you take this issue forward with input from others rather than me please. On Fri, Aug 7, 2020 at 2:19 PM Tomas Eduardo Fernandez Lobbe (Jira) < > Backward-Compatible Replication > --- > > Key: SOLR-14708 > URL: https://issues.apache.org/jira/browse/SOLR-14708 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Marcus Eagan >Priority: Critical > > In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed > that we remove master/slave terminology from the Solr codebase. Now that's > complete, we need to ensure it is backward compatible to support rolling > upgrades from 8.7.x to 9.x because we really ought not to make it harder to > upgrade Solr. > Tomas offered a helpful path in a now abandoned PR: > {quote}One way to get back compatibility and rolling upgrades could be to > make 9.x code be able to read previous formats, but write new format, and > make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a > rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to > 8.7 would still work. > All the code other than the requests/responses could be changed in 8_x > branch, in addition to master. > {quote} > The approach that we will take is to add a ternary operator in 9_X to accept > parameter values for the legacy verbiage, or leader/follower, but only write > leader/follower. We need to then make 8_x work in the inverse way. The burden > here is not on that proposal or on the code in my view. Instead, the burden > is on the test plan. > If anyone has any guidance please share but here are my thoughts: > Case A: > Test the case where a user is running a standalone cluster in 8 with three > nodes but then updates one of the nodes. > Case B: > Test the case where a user is running a mixed cluster standalone cluster, and > the leader node is forced to fail and then is brought back. > Case C: > A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a > rolling upgrade and a follower needs to become leader. > I know haven't listed all possible scenarios or everything that could happen. > Please let me know if you have thoughts or guidance on how best to accomplish > this work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14708) Backward-Compatible Replication
[ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173195#comment-17173195 ] Marcus Eagan commented on SOLR-14708: - Also, even with this change aside, Solr 9 is very far from back compatibility in other areas. > Backward-Compatible Replication > --- > > Key: SOLR-14708 > URL: https://issues.apache.org/jira/browse/SOLR-14708 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Marcus Eagan >Priority: Critical > > In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed > that we remove master/slave terminology from the Solr codebase. Now that's > complete, we need to ensure it is backward compatible to support rolling > upgrades from 8.7.x to 9.x because we really ought not to make it harder to > upgrade Solr. > Tomas offered a helpful path in a now abandoned PR: > {quote}One way to get back compatibility and rolling upgrades could be to > make 9.x code be able to read previous formats, but write new format, and > make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a > rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to > 8.7 would still work. > All the code other than the requests/responses could be changed in 8_x > branch, in addition to master. > {quote} > The approach that we will take is to add a ternary operator in 9_X to accept > parameter values for the legacy verbiage, or leader/follower, but only write > leader/follower. We need to then make 8_x work in the inverse way. The burden > here is not on that proposal or on the code in my view. Instead, the burden > is on the test plan. > If anyone has any guidance please share but here are my thoughts: > Case A: > Test the case where a user is running a standalone cluster in 8 with three > nodes but then updates one of the nodes. > Case B: > Test the case where a user is running a mixed cluster standalone cluster, and > the leader node is forced to fail and then is brought back. > Case C: > A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a > rolling upgrade and a follower needs to become leader. > I know haven't listed all possible scenarios or everything that could happen. > Please let me know if you have thoughts or guidance on how best to accomplish > this work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14708) Backward-Compatible Replication
[ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173011#comment-17173011 ] Marcus Eagan edited comment on SOLR-14708 at 8/7/20, 2:54 PM: -- Honestly [~tflobbe] there seems to be a lot of dependencies and other issues that challenge it. I will have to review in more closely with dedicated next week. Backward compatibility touches various parts of the application and will require a coordinated effort probably from you, AB, and may others. FastLRU Cache seems to exist in 8.6 still. This causes problems for replication in the tests. was (Author: marcussorealheis): Honestly [~tflobbe] there seems to be a lot of dependencies and other issues that challenge it. I will have to review in more closely with dedicated next week. Backward compatibility touches various parts of the application and will require a coordinated effort probably from you, AB, and may others. > Backward-Compatible Replication > --- > > Key: SOLR-14708 > URL: https://issues.apache.org/jira/browse/SOLR-14708 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Marcus Eagan >Priority: Critical > > In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed > that we remove master/slave terminology from the Solr codebase. Now that's > complete, we need to ensure it is backward compatible to support rolling > upgrades from 8.7.x to 9.x because we really ought not to make it harder to > upgrade Solr. > Tomas offered a helpful path in a now abandoned PR: > {quote}One way to get back compatibility and rolling upgrades could be to > make 9.x code be able to read previous formats, but write new format, and > make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a > rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to > 8.7 would still work. > All the code other than the requests/responses could be changed in 8_x > branch, in addition to master. > {quote} > The approach that we will take is to add a ternary operator in 9_X to accept > parameter values for the legacy verbiage, or leader/follower, but only write > leader/follower. We need to then make 8_x work in the inverse way. The burden > here is not on that proposal or on the code in my view. Instead, the burden > is on the test plan. > If anyone has any guidance please share but here are my thoughts: > Case A: > Test the case where a user is running a standalone cluster in 8 with three > nodes but then updates one of the nodes. > Case B: > Test the case where a user is running a mixed cluster standalone cluster, and > the leader node is forced to fail and then is brought back. > Case C: > A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a > rolling upgrade and a follower needs to become leader. > I know haven't listed all possible scenarios or everything that could happen. > Please let me know if you have thoughts or guidance on how best to accomplish > this work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14708) Backward-Compatible Replication
[ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17173011#comment-17173011 ] Marcus Eagan commented on SOLR-14708: - Honestly [~tflobbe] there seems to be a lot of dependencies and other issues that challenge it. I will have to review in more closely with dedicated next week. Backward compatibility touches various parts of the application and will require a coordinated effort probably from you, AB, and may others. > Backward-Compatible Replication > --- > > Key: SOLR-14708 > URL: https://issues.apache.org/jira/browse/SOLR-14708 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Marcus Eagan >Priority: Critical > > In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed > that we remove master/slave terminology from the Solr codebase. Now that's > complete, we need to ensure it is backward compatible to support rolling > upgrades from 8.7.x to 9.x because we really ought not to make it harder to > upgrade Solr. > Tomas offered a helpful path in a now abandoned PR: > {quote}One way to get back compatibility and rolling upgrades could be to > make 9.x code be able to read previous formats, but write new format, and > make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a > rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to > 8.7 would still work. > All the code other than the requests/responses could be changed in 8_x > branch, in addition to master. > {quote} > The approach that we will take is to add a ternary operator in 9_X to accept > parameter values for the legacy verbiage, or leader/follower, but only write > leader/follower. We need to then make 8_x work in the inverse way. The burden > here is not on that proposal or on the code in my view. Instead, the burden > is on the test plan. > If anyone has any guidance please share but here are my thoughts: > Case A: > Test the case where a user is running a standalone cluster in 8 with three > nodes but then updates one of the nodes. > Case B: > Test the case where a user is running a mixed cluster standalone cluster, and > the leader node is forced to fail and then is brought back. > Case C: > A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a > rolling upgrade and a follower needs to become leader. > I know haven't listed all possible scenarios or everything that could happen. > Please let me know if you have thoughts or guidance on how best to accomplish > this work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14708) Backward-Compatible Replication
[ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17172952#comment-17172952 ] Marcus Eagan commented on SOLR-14708: - There is also a very strong chance that I am not doing this right because it looks like some things have changed since I last ran a cluster in standalone mode. > Backward-Compatible Replication > --- > > Key: SOLR-14708 > URL: https://issues.apache.org/jira/browse/SOLR-14708 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Marcus Eagan >Priority: Critical > > In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed > that we remove master/slave terminology from the Solr codebase. Now that's > complete, we need to ensure it is backward compatible to support rolling > upgrades from 8.7.x to 9.x because we really ought not to make it harder to > upgrade Solr. > Tomas offered a helpful path in a now abandoned PR: > {quote}One way to get back compatibility and rolling upgrades could be to > make 9.x code be able to read previous formats, but write new format, and > make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a > rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to > 8.7 would still work. > All the code other than the requests/responses could be changed in 8_x > branch, in addition to master. > {quote} > The approach that we will take is to add a ternary operator in 9_X to accept > parameter values for the legacy verbiage, or leader/follower, but only write > leader/follower. We need to then make 8_x work in the inverse way. The burden > here is not on that proposal or on the code in my view. Instead, the burden > is on the test plan. > If anyone has any guidance please share but here are my thoughts: > Case A: > Test the case where a user is running a standalone cluster in 8 with three > nodes but then updates one of the nodes. > Case B: > Test the case where a user is running a mixed cluster standalone cluster, and > the leader node is forced to fail and then is brought back. > Case C: > A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a > rolling upgrade and a follower needs to become leader. > I know haven't listed all possible scenarios or everything that could happen. > Please let me know if you have thoughts or guidance on how best to accomplish > this work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14708) Backward-Compatible Replication
[ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17172947#comment-17172947 ] Marcus Eagan edited comment on SOLR-14708 at 8/7/20, 7:18 AM: -- Also, master/slave is not very documented as well. It is straightforward, but annoying to work with, for sure because there is little documentation. was (Author: marcussorealheis): Also, master/slave is not very documented as well. It is straightforward, but annoying to work with, for sure. > Backward-Compatible Replication > --- > > Key: SOLR-14708 > URL: https://issues.apache.org/jira/browse/SOLR-14708 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Marcus Eagan >Priority: Critical > > In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed > that we remove master/slave terminology from the Solr codebase. Now that's > complete, we need to ensure it is backward compatible to support rolling > upgrades from 8.7.x to 9.x because we really ought not to make it harder to > upgrade Solr. > Tomas offered a helpful path in a now abandoned PR: > {quote}One way to get back compatibility and rolling upgrades could be to > make 9.x code be able to read previous formats, but write new format, and > make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a > rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to > 8.7 would still work. > All the code other than the requests/responses could be changed in 8_x > branch, in addition to master. > {quote} > The approach that we will take is to add a ternary operator in 9_X to accept > parameter values for the legacy verbiage, or leader/follower, but only write > leader/follower. We need to then make 8_x work in the inverse way. The burden > here is not on that proposal or on the code in my view. Instead, the burden > is on the test plan. > If anyone has any guidance please share but here are my thoughts: > Case A: > Test the case where a user is running a standalone cluster in 8 with three > nodes but then updates one of the nodes. > Case B: > Test the case where a user is running a mixed cluster standalone cluster, and > the leader node is forced to fail and then is brought back. > Case C: > A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a > rolling upgrade and a follower needs to become leader. > I know haven't listed all possible scenarios or everything that could happen. > Please let me know if you have thoughts or guidance on how best to accomplish > this work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14708) Backward-Compatible Replication
[ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17172947#comment-17172947 ] Marcus Eagan commented on SOLR-14708: - Also, master/slave is not very documented as well. It is straightforward, but annoying to work with, for sure. > Backward-Compatible Replication > --- > > Key: SOLR-14708 > URL: https://issues.apache.org/jira/browse/SOLR-14708 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Marcus Eagan >Priority: Critical > > In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed > that we remove master/slave terminology from the Solr codebase. Now that's > complete, we need to ensure it is backward compatible to support rolling > upgrades from 8.7.x to 9.x because we really ought not to make it harder to > upgrade Solr. > Tomas offered a helpful path in a now abandoned PR: > {quote}One way to get back compatibility and rolling upgrades could be to > make 9.x code be able to read previous formats, but write new format, and > make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a > rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to > 8.7 would still work. > All the code other than the requests/responses could be changed in 8_x > branch, in addition to master. > {quote} > The approach that we will take is to add a ternary operator in 9_X to accept > parameter values for the legacy verbiage, or leader/follower, but only write > leader/follower. We need to then make 8_x work in the inverse way. The burden > here is not on that proposal or on the code in my view. Instead, the burden > is on the test plan. > If anyone has any guidance please share but here are my thoughts: > Case A: > Test the case where a user is running a standalone cluster in 8 with three > nodes but then updates one of the nodes. > Case B: > Test the case where a user is running a mixed cluster standalone cluster, and > the leader node is forced to fail and then is brought back. > Case C: > A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a > rolling upgrade and a follower needs to become leader. > I know haven't listed all possible scenarios or everything that could happen. > Please let me know if you have thoughts or guidance on how best to accomplish > this work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14708) Backward-Compatible Replication
[ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17172946#comment-17172946 ] Marcus Eagan commented on SOLR-14708: - so far, [~tflobbe] test Case A fails in a few ways: Replication is not working properly. Recovery did not happen appropriately. Admin UI doesn't work either. There is more work to do on the back-compat front. > Backward-Compatible Replication > --- > > Key: SOLR-14708 > URL: https://issues.apache.org/jira/browse/SOLR-14708 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Marcus Eagan >Priority: Critical > > In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed > that we remove master/slave terminology from the Solr codebase. Now that's > complete, we need to ensure it is backward compatible to support rolling > upgrades from 8.7.x to 9.x because we really ought not to make it harder to > upgrade Solr. > Tomas offered a helpful path in a now abandoned PR: > {quote}One way to get back compatibility and rolling upgrades could be to > make 9.x code be able to read previous formats, but write new format, and > make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a > rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to > 8.7 would still work. > All the code other than the requests/responses could be changed in 8_x > branch, in addition to master. > {quote} > The approach that we will take is to add a ternary operator in 9_X to accept > parameter values for the legacy verbiage, or leader/follower, but only write > leader/follower. We need to then make 8_x work in the inverse way. The burden > here is not on that proposal or on the code in my view. Instead, the burden > is on the test plan. > If anyone has any guidance please share but here are my thoughts: > Case A: > Test the case where a user is running a standalone cluster in 8 with three > nodes but then updates one of the nodes. > Case B: > Test the case where a user is running a mixed cluster standalone cluster, and > the leader node is forced to fail and then is brought back. > Case C: > A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a > rolling upgrade and a follower needs to become leader. > I know haven't listed all possible scenarios or everything that could happen. > Please let me know if you have thoughts or guidance on how best to accomplish > this work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8626) standardise test class naming
[ https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17172712#comment-17172712 ] Marcus Eagan commented on LUCENE-8626: -- There are many many areas where I am looking to improve the developer experience and the code hygiene. I'm not some guru of clean code or anything, but I am starting go through my laundry list of things that drive me (and others) nuts and reduces the overall quality of the project. I intend to add a pre-commit check to enforce this and other standards as they come through. > standardise test class naming > - > > Key: LUCENE-8626 > URL: https://issues.apache.org/jira/browse/LUCENE-8626 > Project: Lucene - Core > Issue Type: Test >Reporter: Christine Poerschke >Priority: Major > Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, > SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch > > > This was mentioned and proposed on the dev mailing list. Starting this ticket > here to start to make it happen? > History: This ticket was created as > https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got > JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8626) standardise test class naming
[ https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17172709#comment-17172709 ] Marcus Eagan commented on LUCENE-8626: -- [~cpoerschke] Thank you very much for kicking this effort off back in 2018. This issue has many implications for problems. And for what I am working on, there is a detriment to my productivity because of it. I'm sure I am not alone. If you don't mind, I'd like to take this effort a bit further and to completion via a PR. > standardise test class naming > - > > Key: LUCENE-8626 > URL: https://issues.apache.org/jira/browse/LUCENE-8626 > Project: Lucene - Core > Issue Type: Test >Reporter: Christine Poerschke >Priority: Major > Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, > SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch > > > This was mentioned and proposed on the dev mailing list. Starting this ticket > here to start to make it happen? > History: This ticket was created as > https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got > JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171755#comment-17171755 ] Marcus Eagan commented on SOLR-14702: - Makes sense to me. Sent via Superhuman iOS ( https://sprh.mn/?vip=m...@marcuseagan.com ) > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 13h 40m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169479#comment-17169479 ] Marcus Eagan edited comment on SOLR-14702 at 8/4/20, 5:40 PM: -- [~o...@apache.org] and [~simonwillnauer] agree, at least, on Twitter: [https://twitter.com/otisg/status/127361291415937] Well, I know they both agree. They're both reasonable and kind. was (Author: marcussorealheis): [~o...@apache.org] and [~simonwillnauer] agree, ate least, on Twitter: [https://twitter.com/otisg/status/127361291415937] Well, I know they both agree. They're both reasonable and kind. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 12h 40m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14708) Backward-Compatible Replication
[ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-14708: Description: In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed that we remove master/slave terminology from the Solr codebase. Now that's complete, we need to ensure it is backward compatible to support rolling upgrades from 8.7.x to 9.x because we really ought not to make it harder to upgrade Solr. Tomas offered a helpful path in a now abandoned PR: {quote}One way to get back compatibility and rolling upgrades could be to make 9.x code be able to read previous formats, but write new format, and make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 8.7 would still work. All the code other than the requests/responses could be changed in 8_x branch, in addition to master. {quote} The approach that we will take is to add a ternary operator in 9_X to accept parameter values for the legacy verbiage, or leader/follower, but only write leader/follower. We need to then make 8_x work in the inverse way. The burden here is not on that proposal or on the code in my view. Instead, the burden is on the test plan. If anyone has any guidance please share but here are my thoughts: Case A: Test the case where a user is running a standalone cluster in 8 with three nodes but then updates one of the nodes. Case B: Test the case where a user is running a mixed cluster standalone cluster, and the leader node is forced to fail and then is brought back. Case C: A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a rolling upgrade and a follower needs to become leader. I know haven't listed all possible scenarios or everything that could happen. Please let me know if you have thoughts or guidance on how best to accomplish this work. > Backward-Compatible Replication > --- > > Key: SOLR-14708 > URL: https://issues.apache.org/jira/browse/SOLR-14708 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Marcus Eagan >Priority: Critical > > In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed > that we remove master/slave terminology from the Solr codebase. Now that's > complete, we need to ensure it is backward compatible to support rolling > upgrades from 8.7.x to 9.x because we really ought not to make it harder to > upgrade Solr. > Tomas offered a helpful path in a now abandoned PR: > {quote}One way to get back compatibility and rolling upgrades could be to > make 9.x code be able to read previous formats, but write new format, and > make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a > rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to > 8.7 would still work. > All the code other than the requests/responses could be changed in 8_x > branch, in addition to master. > {quote} > The approach that we will take is to add a ternary operator in 9_X to accept > parameter values for the legacy verbiage, or leader/follower, but only write > leader/follower. We need to then make 8_x work in the inverse way. The burden > here is not on that proposal or on the code in my view. Instead, the burden > is on the test plan. > If anyone has any guidance please share but here are my thoughts: > Case A: > Test the case where a user is running a standalone cluster in 8 with three > nodes but then updates one of the nodes. > Case B: > Test the case where a user is running a mixed cluster standalone cluster, and > the leader node is forced to fail and then is brought back. > Case C: > A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a > rolling upgrade and a follower needs to become leader. > I know haven't listed all possible scenarios or everything that could happen. > Please let me know if you have thoughts or guidance on how best to accomplish > this work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14708) Backward-Compatible Replication
[ https://issues.apache.org/jira/browse/SOLR-14708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-14708: Environment: (was: In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed that we remove master/slave terminology from the Solr codebase. Now that's complete, we need to ensure it is backward compatible to support rolling upgrades from 8.7.x to 9.x because we really ought not to make it harder to upgrade Solr. Tomas offered a helpful path in a now abandoned PR: {quote}One way to get back compatibility and rolling upgrades could be to make 9.x code be able to read previous formats, but write new format, and make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 8.7 would still work. All the code other than the requests/responses could be changed in 8_x branch, in addition to master. {quote} The approach that we will take is to add a ternary operator in 9_X to accept parameter values for the legacy verbiage, or leader/follower, but only write leader/follower. We need to then make 8_x work in the inverse way. The burden here is not on that proposal or on the code in my view. Instead, the burden is on the test plan. If anyone has any guidance please share but here are my thoughts: Case A: Test the case where a user is running a standalone cluster in 8 with three nodes but then updates one of the nodes. Case B: Test the case where a user is running a mixed cluster standalone cluster, and the leader node is forced to fail and then is brought back. Case C: A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a rolling upgrade and a follower needs to become leader. I know haven't listed all possible scenarios or everything that could happen. Please let me know if you have thoughts or guidance on how best to accomplish this work.) > Backward-Compatible Replication > --- > > Key: SOLR-14708 > URL: https://issues.apache.org/jira/browse/SOLR-14708 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Marcus Eagan >Priority: Critical > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14708) Backward-Compatible Replication
Marcus Eagan created SOLR-14708: --- Summary: Backward-Compatible Replication Key: SOLR-14708 URL: https://issues.apache.org/jira/browse/SOLR-14708 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Environment: In [SOLR-14702|https://issues.apache.org/jira/browse/SOLR-14702] I proposed that we remove master/slave terminology from the Solr codebase. Now that's complete, we need to ensure it is backward compatible to support rolling upgrades from 8.7.x to 9.x because we really ought not to make it harder to upgrade Solr. Tomas offered a helpful path in a now abandoned PR: {quote}One way to get back compatibility and rolling upgrades could be to make 9.x code be able to read previous formats, but write new format, and make 8.x (since 8.7) read new and old, but write old? Anyone wanting to do a rolling upgrade to 9 would have to be on at least 8.7. Rolling upgrades to 8.7 would still work. All the code other than the requests/responses could be changed in 8_x branch, in addition to master. {quote} The approach that we will take is to add a ternary operator in 9_X to accept parameter values for the legacy verbiage, or leader/follower, but only write leader/follower. We need to then make 8_x work in the inverse way. The burden here is not on that proposal or on the code in my view. Instead, the burden is on the test plan. If anyone has any guidance please share but here are my thoughts: Case A: Test the case where a user is running a standalone cluster in 8 with three nodes but then updates one of the nodes. Case B: Test the case where a user is running a mixed cluster standalone cluster, and the leader node is forced to fail and then is brought back. Case C: A SolrCloud cluster that has a mix of 8 and 9 nodes goes down during a rolling upgrade and a follower needs to become leader. I know haven't listed all possible scenarios or everything that could happen. Please let me know if you have thoughts or guidance on how best to accomplish this work. Reporter: Marcus Eagan -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170621#comment-17170621 ] Marcus Eagan commented on SOLR-14702: - This was not addressed here in the Jira but Tomas raised a really important point in the PR. I'm revisiting my initial PR (leader/follower) and finishing up for the first phase. I think the second phase should be backward compatibility. The third phase should be the build pipeline tools. I don't know how urgent it should be. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 11h > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170569#comment-17170569 ] Marcus Eagan commented on SOLR-14702: - {quote}I think this is really off? Definitely alerts will be different. As we both agreed, the architectures are different and so are the things to monitor/alert on. This is no different than having Solr in SolrCloud mode running in completely different infrastructure (say, Kubernetes vs bare metal), the alerts and actions to take are different. If you have enough clusters to need a "reminder" of the mode they are in running on you most likely have a tool to track it. {quote} My point was that people will take logical shortcuts to comprehend, looking for keywords and deductions. SolrCloud on Kubernetes vs bare metal is non-analagous, especially considering you can run Kubernetes on bare metal. Kubernetes is just server orchestration software. You can put it on EC2, baremetal, or wherever you can find 4 GB of RAM and 2 CPUs. Regardless of the tracking/alerting tool, the output of it should be as obvious as possible. Context switching with conflicting terms is a recipe for production outages. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 7h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170566#comment-17170566 ] Marcus Eagan commented on SOLR-14702: - {quote}ReplicationHandler/IndexFetcher code continuously log including "master" and "slave" that, in the context of both recoveries and replication for TLOG/PULL replicas, actually refer to leaders and followers. {quote} Can you clarify? I think you are missing a word or clause here. I don't understand what you are saying. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 7h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-14702: Comment: was deleted (was: {quote}Also, Is the secondary second to what? is there some order of things? If there is a repeater, the "secondary" is not actually the second to get the index. {quote} Come again?) > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 7h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170565#comment-17170565 ] Marcus Eagan commented on SOLR-14702: - {quote}Also, Is the secondary second to what? is there some order of things? If there is a repeater, the "secondary" is not actually the second to get the index. {quote} Come again? > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 7h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170546#comment-17170546 ] Marcus Eagan commented on SOLR-14702: - Btw, thanks for being so engaged in the ticket and driving it toward resolution. All constructive feedback is welcome, especially substantive feedback that supports a swift and robust resolution for the community. Very much appreciated. Usability is my top priority. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170544#comment-17170544 ] Marcus Eagan commented on SOLR-14702: - Ahhh. Thanks for the clarification. So, yeah. I guess you are in effect arguing in favor of Pager Duty alerts that read (for illustrative and rhetorical pruposes): Hey, legacy leader went down in Leibniz cluster. As opposed to - Hey, the primary node went down in the Ramanujan cluster. It's very clear in the second example which architecture was impacted and what action needs to be taken. In the Leibniz cluster are we talking about the master/slave legacy architecture or are we talking about the leader/follower implementation that came first as is the case of SolrCloud? I understand you but I disagree with you. Are you willing to do the work to get the leader/follower branch up to back-compat? > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170533#comment-17170533 ] Marcus Eagan commented on SOLR-14702: - {quote}Also, Is the secondary second to what? is there some order of things? If there is a repeater, the "secondary" is not actually the second to get the index. {quote} If there is a repeater it functions like both a secondary and primary. I included that in the PR. Do you have any more thoughts on what needs to change in the code beyond the name, to support backward compatibility? I'm really interested in that stuff because I have to do that at some point regardless of what the name is, ultimately. I also would like a firm commitment from the community on how we ensure that this doesn't linger beyond the initial version. I don't want to see master/slave ever again and I think others, some of whom I tried to recruit for the project, would like to see it either. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 7.5h > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170528#comment-17170528 ] Marcus Eagan commented on SOLR-14702: - Tomas, {quote}because I have demonstrated the architectures are different I don't think that was ever in doubt? {quote} These were your words a few hours ago brother: {quote}it's the same in both architecture IMO {quote} It's not the same architecture so glad we agree on it. I think because the support models are significant different, two different names could actually be beneficial as Shawn Heisey alluded to, especially for independent consultants like working with multiple Solr footprints of different versions and replication modes. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 7.5h > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170475#comment-17170475 ] Marcus Eagan commented on SOLR-14702: - [~erickerickson]Thanks for the help. The masterURL reference should be removed in the latest state of the master but I did not catch the secondary typo in the config. I looked and didn't see it. Thanks for helping out here. Pushing up the change. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 6h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170473#comment-17170473 ] Marcus Eagan edited comment on SOLR-14702 at 8/4/20, 12:00 AM: --- [~tflobbe] I view almost any comment that detracts from the goal of getting master/slave out of the codebase to a distraction from that which is imperative and of the utmost importance. If you have a really compelling reason other than you like it because I have demonstrated the architectures are different then I think you should drop it. was (Author: marcussorealheis): [~tflobbe] I view almost any comment that detracts from the goal of getting master/slave out of the codebase to a distraction from that which is imperative and of the utmost importance. If you have a really compelling reason other than you like it because I have demonstrated the architectures are different than I think you should drop it. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 6h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170474#comment-17170474 ] Marcus Eagan commented on SOLR-14702: - bq. We already have a difficult time getting users to understand the complexities involved, particularly because SolrCloud actually does utilize replication, in a way that's quite different than legacy. If we use the same terms for the different things found in the two different modes, that confusion is going to get worse. +1 > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 6h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170473#comment-17170473 ] Marcus Eagan commented on SOLR-14702: - [~tflobbe] I view almost any comment that detracts from the goal of getting master/slave out of the codebase to a distraction from that which is imperative and of the utmost importance. If you have a really compelling reason other than you like it because I have demonstrated the architectures are different than I think you should drop it. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Attachments: SOLR-14742-testfix.patch > > Time Spent: 6h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170466#comment-17170466 ] Marcus Eagan commented on SOLR-14702: - Again, I don't care I just want the words removed and curious about the technical basis for your objection. In non-SolrCloud, there is no indexing at all when the primary node goes down. In SolrCloud, a follower can emerge as the leader without human intervention. Those are different architectures in simple terms. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170458#comment-17170458 ] Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 11:17 PM: --- hey guys, I opened a PR for both but the longer we delay on merging the more trouble it will be to get it in. So I will update the leader/follower one (the first one actually) that fell behind a bit and didn't get as much love, but please don't hesitate to continue to work on whichever of the two PRs you prefer because I'm frankly sick of reading the words master and slave. It's really stressful. And [~tflobbe] I think your analysis sheds light on the fact that leader/follower is not what's happening in non-SolrCloud mode. Replicas are not replicas of a leader. They are replicas. If the "leader" fails the state of the cluster is very different for an end-user managing the cluster compared to when a leader goes down in SolrCloud. They are very different. This is an aside: Can I ask why you support colliding terms for reasons other than you "personally like to use 'leader/follower?'" As I said, I really don't care. I just want it to leave the code base so I never have to see it again, same with others who don't like to think about it. was (Author: marcussorealheis): hey guys, I opened a PR for both but the longer we delay on merging the more trouble it will be to get it in. So I will keep update the leader/follower one that fell behind a bit and didn't get as much love, but please don't hesitate to continue to work on whichever of the two PRs you prefer because I'm frankly sick of reading the words master and slave. It's really stressful. And [~tflobbe] I think your analysis sheds light on the fact that leader/follower is not what's happening in non-SolrCloud mode. Replicas are not replicas of a leader. They are replicas. If the "leader" fails the state of the cluster is very different for an end-user managing the cluster compared to when a leader goes down in SolrCloud. They are very different. Can I ask why you support colliding terms for reasons other than you "personally like to use 'leader/follower?'" > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170458#comment-17170458 ] Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 11:14 PM: --- hey guys, I opened a PR for both but the longer we delay on merging the more trouble it will be to get it in. So I will keep update the leader/follower one that fell behind a bit and didn't get as much love, but please don't hesitate to continue to work on whichever of the two PRs you prefer because I'm frankly sick of reading the words master and slave. It's really stressful. And [~tflobbe] I think your analysis sheds light on the fact that leader/follower is not what's happening in non-SolrCloud mode. Replicas are not replicas of a leader. They are replicas. If the "leader" fails the state of the cluster is very different for an end-user managing the cluster compared to when a leader goes down in SolrCloud. They are very different. Can I ask why you support colliding terms for reasons other than you "personally like to use 'leader/follower?'" was (Author: marcussorealheis): hey guys, I opened a PR for both but the longer we delay on merging the more trouble it will be to get it in. So I will keep update the leader/follower one that fell behind a bit and didn't get as much love, but please don't hesitate to continue to work on whichever of the two PRs you prefer because I'm frankly sick of reading the words master and slave. It's really stressful. And [~tflobbe] I think your analysis sheds light on the fact that leader/follower is not what's happening in non-SolrCloud mode. Replicas are replicas of a leader. They are replicas. If the "leader" fails the state of the cluster is very different for an end-user managing the cluster compared to when a leader goes down in SolrCloud. They are very different. Can I ask why you support colliding terms for reasons other than you "personally like to use 'leader/follower?'" > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170458#comment-17170458 ] Marcus Eagan commented on SOLR-14702: - hey guys, I opened a PR for both but the longer we delay on merging the more trouble it will be to get it in. So I will keep update the leader/follower one that fell behind a bit and didn't get as much love, but please don't hesitate to continue to work on whichever of the two PRs you prefer because I'm frankly sick of reading the words master and slave. It's really stressful. And [~tflobbe] I think your analysis sheds light on the fact that leader/follower is not what's happening in non-SolrCloud mode. Replicas are replicas of a leader. They are replicas. If the "leader" the state of the cluster is very different for an end-user managing the cluster compared to when a leader goes down in SolrCloud. They are very different. Can I ask why you support colliding terms for reasons other than you "personally like to use 'leader/follower?'" > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170458#comment-17170458 ] Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 11:12 PM: --- hey guys, I opened a PR for both but the longer we delay on merging the more trouble it will be to get it in. So I will keep update the leader/follower one that fell behind a bit and didn't get as much love, but please don't hesitate to continue to work on whichever of the two PRs you prefer because I'm frankly sick of reading the words master and slave. It's really stressful. And [~tflobbe] I think your analysis sheds light on the fact that leader/follower is not what's happening in non-SolrCloud mode. Replicas are replicas of a leader. They are replicas. If the "leader" fails the state of the cluster is very different for an end-user managing the cluster compared to when a leader goes down in SolrCloud. They are very different. Can I ask why you support colliding terms for reasons other than you "personally like to use 'leader/follower?'" was (Author: marcussorealheis): hey guys, I opened a PR for both but the longer we delay on merging the more trouble it will be to get it in. So I will keep update the leader/follower one that fell behind a bit and didn't get as much love, but please don't hesitate to continue to work on whichever of the two PRs you prefer because I'm frankly sick of reading the words master and slave. It's really stressful. And [~tflobbe] I think your analysis sheds light on the fact that leader/follower is not what's happening in non-SolrCloud mode. Replicas are replicas of a leader. They are replicas. If the "leader" the state of the cluster is very different for an end-user managing the cluster compared to when a leader goes down in SolrCloud. They are very different. Can I ask why you support colliding terms for reasons other than you "personally like to use 'leader/follower?'" > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h 50m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170383#comment-17170383 ] Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 7:44 PM: -- [~erickerickson] these are the tests: org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication org.apache.solr.handler.TestReplicationHandler.doTestRepeater org.apache.solr.handler.TestReplicationHandler.doTestStressReplication org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl was (Author: marcussorealheis): [~erickerickson] these are the tests: {{org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication org.apache.solr.handler.TestReplicationHandler.doTestRepeater org.apache.solr.handler.TestReplicationHandler.doTestStressReplication org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl}} > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h 20m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170383#comment-17170383 ] Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 7:44 PM: -- [~erickerickson] these are the tests: {{org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication org.apache.solr.handler.TestReplicationHandler.doTestRepeater org.apache.solr.handler.TestReplicationHandler.doTestStressReplication org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl}} was (Author: marcussorealheis): [~erickerickson] these are the tests: org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}} {{org.apache.solr.handler.TestReplicationHandler.doTestRepeater org.apache.solr.handler.TestReplicationHandler.doTestStressReplication org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h 20m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170383#comment-17170383 ] Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 7:43 PM: -- [~erickerickson] these are the tests: org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}} {{org.apache.solr.handler.TestReplicationHandler.doTestRepeater org.apache.solr.handler.TestReplicationHandler.doTestStressReplication org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl was (Author: marcussorealheis): [~erickerickson] these are the tests: { {{{org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}} {{org.apache.solr.handler.TestReplicationHandler.doTestRepeater org.apache.solr.handler.TestReplicationHandler.doTestStressReplication org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h 20m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170383#comment-17170383 ] Marcus Eagan edited comment on SOLR-14702 at 8/3/20, 7:43 PM: -- [~erickerickson] these are the tests: { {{{org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}} {{org.apache.solr.handler.TestReplicationHandler.doTestRepeater org.apache.solr.handler.TestReplicationHandler.doTestStressReplication org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl was (Author: marcussorealheis): [~erickerickson] these are the tests: org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}} }} org.apache.solr.handler.TestReplicationHandler.doTestRepeater org.apache.solr.handler.TestReplicationHandler.doTestStressReplication org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h 20m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170383#comment-17170383 ] Marcus Eagan commented on SOLR-14702: - [~erickerickson] these are the tests: org.apache.solr.handler.TestReplicationHandler.testRateLimitedReplication}} }} org.apache.solr.handler.TestReplicationHandler.doTestRepeater org.apache.solr.handler.TestReplicationHandler.doTestStressReplication org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithPrimaryUrl > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h 20m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170143#comment-17170143 ] Marcus Eagan commented on SOLR-14702: - [~janhoy] see this if you haven't: [https://tools.ietf.org/id/draft-knodel-terminology-00.html] Lots of work to do in the Solr and Lucene repos 🙃 > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170124#comment-17170124 ] Marcus Eagan commented on SOLR-14702: - {quote}I think we all appreciate Marcus vulunteering to help with the work. But since he was probably not ware of [~anshum]'s great contribution towards tackling this, by involving the entire user community on the dev list, I wanted to shed light on the existence of the existing discussion. Once that discussion converges, either through consensus or vote, then we can continue discussion on the implementation here and in the PR. If something else than primary/secondary is chosen, then it should be fairly quick to update the patch. {quote} Hi [~janhoy] Thank you for making me aware of the discussion. I did not see it and wasn't made aware of it. I complained about this nomenclature as early of March of last year when I was still at Lucidworks. It received no traction or bias toward action then, so I took it upon myself to rip it out because over the past few weeks I have had the discomfort of focusing a lot more on the open source and had to read it over and over. It drives me mad. I will check out the discussion and share what I have already done. Since there is so much code in so many places, the effort was non-trivial purely because of volume, but I have done it 100% for primary/secondary, and 80% for leader/follower. Let me paste my PR into the user list. Just re-visiting and reviewing the PR gets me riled up so I hope we can find swift resolution on something that happened months ago. Some database technologies created at the same time as Solr never heavily used such nomenclature officially so I'm hopeful for a switft corrective action. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 6h > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14705) Release Smoke Test Script Shows Unusable JDK Version
Marcus Eagan created SOLR-14705: --- Summary: Release Smoke Test Script Shows Unusable JDK Version Key: SOLR-14705 URL: https://issues.apache.org/jira/browse/SOLR-14705 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: release-scripts Affects Versions: master (9.0) Reporter: Marcus Eagan The script works fine, but the help text in the smoke test script needs to be replaced. Should be Java 8 for now and moved to Java 11 when the community is preparing to release Solr 9. :) Here's the output: usage: smokeTestRelease.py [-h] [--tmp-dir PATH] [--not-signed] [--local-keys PATH] [--revision REVISION] [--version X.Y.Z(-ALPHA|-BETA)?] [--test-java9 JAVA9_HOME] [--download-only] url ... I wouldn't touch Java 9 with a ten foot pole, and nor should new releases. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169679#comment-17169679 ] Marcus Eagan commented on SOLR-14702: - >I suggest we stick to one naming convention. leader follower (for both >standalone and cluster modes) I think it is confusing. People won't know which is which, and one goes away, people will be less empowered and clueless. I think running with primary/secondary for the legacy system is good because it lets people know that they are using the standalone mode. I suspect that it could one day go away...although I know there are many in the community that think otherwise. Whatever happens in the future, leader/follower refers to a different mechanism and something architecturally different than what's happening in standalone mode, hence the different names. They need to be tuned different, scaled differently, and managed differently. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 4h 20m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14701) Deprecate Schemaless Mode (Discussion)
[ https://issues.apache.org/jira/browse/SOLR-14701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169654#comment-17169654 ] Marcus Eagan commented on SOLR-14701: - >Even though dev@ list may have been a better place [~ichattopadhyaya] I like to discuss things on the mailing list, but it seems efforts that are in the mailing list mostly result in mostly talk and little action. They do serve to preserve context very well but not much of a forcing function. I think most are flippant about email because it is so polluted in many cases. [~erickerickson] Great suggestion. We should implement it. > Deprecate Schemaless Mode (Discussion) > -- > > Key: SOLR-14701 > URL: https://issues.apache.org/jira/browse/SOLR-14701 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Schema and Analysis >Reporter: Marcus Eagan >Priority: Major > > I know this won't be the most popular ticket out there, but I am growing more > and more sympathetic to the idea that we should rip many of the freedoms out > that cause users more harm than not. One of the freedoms I saw time and time > again to cause issues was schemaless mode. It doesn't work as named or > documented, so I think it should be deprecated. > If you use it in production reliably and in a way that cannot be accomplished > another way, I am happy to hear from more knowledgeable folks as to why > deprecation is a bad idea. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169648#comment-17169648 ] Marcus Eagan commented on SOLR-14702: - [~erickerickson] Thanks for the contribution, I like leader/follower as well. My first pull request incorporated the change. The reason I have chose primary/secondary is to vocabulary conflict with the leader/follower usage already in the code base. I guess there is not much overlap but it could still be confusing for some. > Remove Master and Slave from Code Base and Docs > --- > > Key: SOLR-14702 > URL: https://issues.apache.org/jira/browse/SOLR-14702 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Critical > Time Spent: 2h 10m > Remaining Estimate: 0h > > Every time I read _master_ and _slave_, I get pissed. > I think about the last and only time I remember visiting my maternal great > grandpa in Alabama at four years old. He was a sharecropper before WWI, where > he lost his legs, and then he was back to being a sharecropper somehow after > the war. Crazy, I know. I don't know if the world still called his job > sharecropping in 1993, but he was basically a slave—in America. He lived in > the same shack that his father, and his grandfather (born a slave) lived in > down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was > actually born a slave, freed shortly after birth by his owner father. I never > met him, though. He died in the 40s. > Anyway, I cannot police all terms in the repo and do not wish to. This > master/slave shit is archaic and misleading on technical grounds. Thankfully, > there's only a handful of files in code and documentation that still talk > about masters and slaves. We should replace all of them. > There are so many ways to reword it. In fact, unless anyone else objects or > wants to do the grunt work to help my stress levels, I will open the pull > request myself in effort to make this project and community more inviting to > people of all backgrounds and histories. We can have leader/follower, or > primary/secondary, but none of this Master/Slave nonsense. I'm sick of the > garbage. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ 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
[ 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 (v8.3.4#8030
[jira] [Updated] (SOLR-14702) Remove Master and Slave from Code Base and Docs
[ 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
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 created SOLR-14702: --- Summary: Remove Master and Slave from Code Base and Docs Key: SOLR-14702 URL: https://issues.apache.org/jira/browse/SOLR-14702 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: master (9.0) Reporter: Marcus Eagan Every time I read _master_ and _slave_, I get pissed. I think about the last and only time I remember visiting my maternal grandpa in Alabama at four years old. He was a sharecropper before WWI, where he lost his legs, and then he was back to being a sharecropper somehow after the war. Crazy, I know. I don't know if the world still called his job sharecropping in 1993, but he was basically a slave—in America. He lived in the same shack that his father, and his grandfather (born a slave) lived in down in Alabama. Believe it or not, my dad's (born in 1926) grandfather was actually born a slave, freed shortly after birth by his owner father. I never met him, though. He died in the 40s. Anyway, I cannot police all terms in the repo and do not wish to. This master/slave shit is archaic and mis-leading on technical grounds. Thankfully, there's only a handful of files in code and documentation that still talk about masters and slaves. We should replace all of them. There are so many ways to reword it. In fact, unless anyone else objects or wants to do the grunt work to help my stress levels, I will open the pull request myself in effort to make this project and community more inviting to people of all backgrounds and histories. We can have leader/follower, or primary/secondary, but none of this Master/Slave nonsense. I'm sick of the garbage. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14701) Deprecate Schemaless Mode (Discussion)
Marcus Eagan created SOLR-14701: --- Summary: Deprecate Schemaless Mode (Discussion) Key: SOLR-14701 URL: https://issues.apache.org/jira/browse/SOLR-14701 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Schema and Analysis Reporter: Marcus Eagan I know this won't be the most popular ticket out there, but I am growing more and more sympathetic to the idea that we should rip many of the freedoms out that cause users more harm than not. One of the freedoms I saw time and time again to cause issues was schemaless mode. It doesn't work as named or documented, so I think it should be deprecated. If you use it in production reliably and in a way that cannot be accomplished another way, I am happy to hear from more knowledgeable folks as to why deprecation is a bad idea. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14681) Delete Jar with Command
[ https://issues.apache.org/jira/browse/SOLR-14681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-14681: Description: We need to build logic that will delete a jar that represents a package. 1. User should delete the zk entries of the files, 2. Call an http endpoint with DELETE method at /api/cluster/ was:We need to build logic that will delete a jar that represents a package. > Delete Jar with Command > --- > > Key: SOLR-14681 > URL: https://issues.apache.org/jira/browse/SOLR-14681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Package Manager >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Assignee: Noble Paul >Priority: Major > > We need to build logic that will delete a jar that represents a package. > 1. User should delete the zk entries of the files, > 2. Call an http endpoint with DELETE method at /api/cluster/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14681) Delete Jar with Command
[ https://issues.apache.org/jira/browse/SOLR-14681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17166236#comment-17166236 ] Marcus Eagan commented on SOLR-14681: - ^ Spam > Delete Jar with Command > --- > > Key: SOLR-14681 > URL: https://issues.apache.org/jira/browse/SOLR-14681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Package Manager >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Major > > We need to build logic that will delete a jar that represents a package. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14681) Delete Jar with Command
[ https://issues.apache.org/jira/browse/SOLR-14681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17165410#comment-17165410 ] Marcus Eagan commented on SOLR-14681: - [SOLR-14604 |https://issues.apache.org/jira/browse/SOLR-14604]needs this > Delete Jar with Command > --- > > Key: SOLR-14681 > URL: https://issues.apache.org/jira/browse/SOLR-14681 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Package Manager >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Major > > We need to build logic that will delete a jar that represents a package. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14681) Delete Jar with Command
Marcus Eagan created SOLR-14681: --- Summary: Delete Jar with Command Key: SOLR-14681 URL: https://issues.apache.org/jira/browse/SOLR-14681 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Package Manager Affects Versions: master (9.0) Reporter: Marcus Eagan We need to build logic that will delete a jar that represents a package. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14664) Add Plugin Example for Docker
Marcus Eagan created SOLR-14664: --- Summary: Add Plugin Example for Docker Key: SOLR-14664 URL: https://issues.apache.org/jira/browse/SOLR-14664 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Marcus Eagan With the release of 8.6.0 it seems to me that we should be adding an example of adding a plugin to the [docker-solr repo|[https://github.com/docker-solr/docker-solr]]. We could easily add the YASA plugin as an example to the 8.6.0 directory when it is created. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14603) Updating the Restlet Version
[ https://issues.apache.org/jira/browse/SOLR-14603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151464#comment-17151464 ] Marcus Eagan commented on SOLR-14603: - [~ichattopadhyaya] do you mind squash merging the PR against master? > Updating the Restlet Version > > > Key: SOLR-14603 > URL: https://issues.apache.org/jira/browse/SOLR-14603 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, Schema and Analysis >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > > There's not a whole lot of risk here because of the limited surface area of > Restlet in the project. [~ichattopadhyaya] even suggested we could remove it, > which I tend to agree with. > I noticed that the Restlet dependency's location was no longer resolving at: > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet/2.4.0/org.restlet-2.4.0.jar. > Now, of course, I could change it to a location that does resolve or download > directly. However, I looking at the changelog I thought that maybe I should > raise with the community that it an upgrade might be helpful given the CVEs. > I will leave it to the experts as to whether it makes a difference, but > here's the changelog for reference. > The Lucene tests passed when I upgraded to 2.4.3 but I'm still digging in. It > is very likely that 2.4.1 would be better. I'd leave that, again, to the > experts and post my findings. > https://github.com/apache/lucene-solr/pull/1622 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14611) Apache Pulsar Solr Plugin for CDCR
Marcus Eagan created SOLR-14611: --- Summary: Apache Pulsar Solr Plugin for CDCR Key: SOLR-14611 URL: https://issues.apache.org/jira/browse/SOLR-14611 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Components: CDCR, Plugin system Affects Versions: master (9.0) Reporter: Marcus Eagan Solr CDCR is very fragile. It can cause a number of issues in environments with high querying or indexing load. @thelabdude has suggested a strong alternative in Apache Pulsar. Since it won’t be needed by all implementations, I suggest that this feature functionality be developed as a plugin to continue the strategy of keeping core Solr as lean as possible. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14034) remove deprecated min_rf references
[ https://issues.apache.org/jira/browse/SOLR-14034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17148972#comment-17148972 ] Marcus Eagan commented on SOLR-14034: - [~rabikumar.kc] Do you still want to work on this or should someone else take it on? [~cpoerschke] has laid out the steps. Do you need help working with GitHub or anything? > remove deprecated min_rf references > --- > > Key: SOLR-14034 > URL: https://issues.apache.org/jira/browse/SOLR-14034 > Project: Solr > Issue Type: Task >Reporter: Christine Poerschke >Priority: Blocker > Fix For: master (9.0) > > > * {{min_rf}} support was added under SOLR-5468 in version 4.9 > (https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.9.0/solr/solrj/src/java/org/apache/solr/client/solrj/request/UpdateRequest.java#L50) > and deprecated under SOLR-12767 in version 7.6 > (https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.6.0/solr/solrj/src/java/org/apache/solr/client/solrj/request/UpdateRequest.java#L57-L61) > * http://lucene.apache.org/solr/7_6_0/changes/Changes.html and > https://lucene.apache.org/solr/guide/8_0/major-changes-in-solr-8.html#solr-7-6 > both clearly mention the deprecation > This ticket is to fully remove {{min_rf}} references in code, tests and > documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14022) Deprecate CDCR from Solr in 8.x
[ https://issues.apache.org/jira/browse/SOLR-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17148971#comment-17148971 ] Marcus Eagan commented on SOLR-14022: - [~ichattopadhyaya][~ctargett][~thelabdude] Do you think we shoul build up a Pulsar plugin for Solr CDCR? That seems like it might be a very popular but not always necessary add-on. > Deprecate CDCR from Solr in 8.x > --- > > Key: SOLR-14022 > URL: https://issues.apache.org/jira/browse/SOLR-14022 > Project: Solr > Issue Type: Improvement > Components: CDCR >Reporter: Joel Bernstein >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > > This ticket will deprecate CDCR in Solr 8x. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14604) Uninstall Command for the Plugin Framework
Marcus Eagan created SOLR-14604: --- Summary: Uninstall Command for the Plugin Framework Key: SOLR-14604 URL: https://issues.apache.org/jira/browse/SOLR-14604 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Components: Plugin system Affects Versions: master (9.0) Reporter: Marcus Eagan I would like to be able to cleanly uninstall all artifacts associated with a plugin and the plugin itself from the command line. I'm not sure how many people want to work with the plugins yet, but as they grow in use and popularity, I'm sure this functionality will be desired by more people than just me. Today, the solution is to run the git command to remove all the files and directories that are un-versioned. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9420) Restlet Dependency
[ https://issues.apache.org/jira/browse/LUCENE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan resolved LUCENE-9420. -- Resolution: Fixed closing and moving to SOLR project for now. > Restlet Dependency > -- > > Key: LUCENE-9420 > URL: https://issues.apache.org/jira/browse/LUCENE-9420 > Project: Lucene - Core > Issue Type: New Feature > Components: core/other >Reporter: Marcus Eagan >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > > I noticed that the Restlet dependency's location was no longer resolving at: > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet/2.4.0/org.restlet-2.4.0.jar. > Now, of course, I could change it to a location that does resolve or download > directly. However, I looking at the changelog I thought that maybe I should > raise with the community that it an upgrade might be helpful given the CVEs. > I will leave it to the experts as to whether it makes a difference, but > here's [the changelog for > reference|https://restlet.talend.com/documentation/2.4/changelog]. > The Lucene tests passed when I upgraded to 2.4.3 but I'm still digging in. > It is very likely that 2.4.1 would be better. I'd leave that, again, to the > experts and post my findings. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9420) Restlet Dependency
Marcus Eagan created LUCENE-9420: Summary: Restlet Dependency Key: LUCENE-9420 URL: https://issues.apache.org/jira/browse/LUCENE-9420 Project: Lucene - Core Issue Type: New Feature Components: core/other Reporter: Marcus Eagan I noticed that the Restlet dependency's location was no longer resolving at: https://repo1.maven.org/maven2/org/restlet/jee/org.restlet/2.4.0/org.restlet-2.4.0.jar. Now, of course, I could change it to a location that does resolve or download directly. However, I looking at the changelog I thought that maybe I should raise with the community that it an upgrade might be helpful given the CVEs. I will leave it to the experts as to whether it makes a difference, but here's [the changelog for reference|https://restlet.talend.com/documentation/2.4/changelog]. The Lucene tests passed when I upgraded to 2.4.3 but I'm still digging in. It is very likely that 2.4.1 would be better. I'd leave that, again, to the experts and post my findings. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13749) Implement support for joining across collections with multiple shards ( XCJF )
[ https://issues.apache.org/jira/browse/SOLR-13749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17145101#comment-17145101 ] Marcus Eagan commented on SOLR-13749: - 🙌🏾 > Implement support for joining across collections with multiple shards ( XCJF ) > -- > > Key: SOLR-13749 > URL: https://issues.apache.org/jira/browse/SOLR-13749 > Project: Solr > Issue Type: New Feature >Reporter: Kevin Watters >Assignee: Gus Heck >Priority: Blocker > Fix For: 8.6 > > Attachments: 2020-03 Smiley with ASF hat.jpeg > > Time Spent: 2.5h > Remaining Estimate: 0h > > This ticket includes 2 query parsers. > The first one is the "Cross collection join filter" (XCJF) parser. This is > the "Cross-collection join filter" query parser. It can do a call out to a > remote collection to get a set of join keys to be used as a filter against > the local collection. > The second one is the Hash Range query parser that you can specify a field > name and a hash range, the result is that only the documents that would have > hashed to that range will be returned. > This query parser will do an intersection based on join keys between 2 > collections. > The local collection is the collection that you are searching against. > The remote collection is the collection that contains the join keys that you > want to use as a filter. > Each shard participating in the distributed request will execute a query > against the remote collection. If the local collection is setup with the > compositeId router to be routed on the join key field, a hash range query is > applied to the remote collection query to only match the documents that > contain a potential match for the documents that are in the local shard/core. > > > Here's some vocab to help with the descriptions of the various parameters. > ||Term||Description|| > |Local Collection|This is the main collection that is being queried.| > |Remote Collection|This is the collection that the XCJFQuery will query to > resolve the join keys.| > |XCJFQuery|The lucene query that executes a search to get back a set of join > keys from a remote collection| > |HashRangeQuery|The lucene query that matches only the documents whose hash > code on a field falls within a specified range.| > > > ||Param ||Required ||Description|| > |collection|Required|The name of the external Solr collection to be queried > to retrieve the set of join key values ( required )| > |zkHost|Optional|The connection string to be used to connect to Zookeeper. > zkHost and solrUrl are both optional parameters, and at most one of them > should be specified. > If neither of zkHost or solrUrl are specified, the local Zookeeper cluster > will be used. ( optional )| > |solrUrl|Optional|The URL of the external Solr node to be queried ( optional > )| > |from|Required|The join key field name in the external collection ( required > )| > |to|Required|The join key field name in the local collection| > |v|See Note|The query to be executed against the external Solr collection to > retrieve the set of join key values. > Note: The original query can be passed at the end of the string or as the > "v" parameter. > It's recommended to use query parameter substitution with the "v" parameter > to ensure no issues arise with the default query parsers.| > |routed| |true / false. If true, the XCJF query will use each shard's hash > range to determine the set of join keys to retrieve for that shard. > This parameter improves the performance of the cross-collection join, but > it depends on the local collection being routed by the toField. If this > parameter is not specified, > the XCJF query will try to determine the correct value automatically.| > |ttl| |The length of time that an XCJF query in the cache will be considered > valid, in seconds. Defaults to 3600 (one hour). > The XCJF query will not be aware of changes to the remote collection, so > if the remote collection is updated, cached XCJF queries may give inaccurate > results. > After the ttl period has expired, the XCJF query will re-execute the join > against the remote collection.| > |_All others_| |Any normal Solr parameter can also be specified as a local > param.| > > Example Solr Config.xml changes: > > {{<}}{{cache}} {{name}}{{=}}{{"hash_vin"}} > {{ }}{{class}}{{=}}{{"solr.LRUCache"}} > {{ }}{{size}}{{=}}{{"128"}} > {{ }}{{initialSize}}{{=}}{{"0"}} > {{ }}{{regenerator}}{{=}}{{"solr.NoOpRegenerator"}}{{/>}} > > {{<}}{{queryParser}} {{name}}{{=}}{{"xcjf"}} > {{class}}{{=}}{{"org.apache.solr.search.join.XCJFQueryParserPlugin"}}{{>}} > {{ }}{{<}}{{str}} {{name}}{{=}}{{"routerField"}}{{>vin}} > {{}} > > {{<}}{{queryParser}} {
[jira] [Commented] (SOLR-14578) Confusing Name in the docs and Test of Auto Add Trigger
[ https://issues.apache.org/jira/browse/SOLR-14578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138939#comment-17138939 ] Marcus Eagan commented on SOLR-14578: - [https://github.com/apache/lucene-solr/pull/1591] > Confusing Name in the docs and Test of Auto Add Trigger > --- > > Key: SOLR-14578 > URL: https://issues.apache.org/jira/browse/SOLR-14578 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling >Affects Versions: master (9.0) >Reporter: Marcus Eagan >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > > In the autoscaling docs, the name of the names of two actions are the same > and it is confusing to users. > See: > {code:java} > { > "set-trigger": { > "name": ".auto_add_replicas", > "event": "nodeLost, > "waitFor": "5s", > "enabled": true, > "actions": [ > { > "name": "auto_add_replicas_plan", > "class": "solr.AutoAddReplicasPlanAction" > }, > { >"name": "auto_add_replicas_plan", // works?, but should be execute plan >"class": "solr.ExecutePlanAction" > } > ] > } > } > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14578) Confusing Name in the docs and Test of Auto Add Trigger
Marcus Eagan created SOLR-14578: --- Summary: Confusing Name in the docs and Test of Auto Add Trigger Key: SOLR-14578 URL: https://issues.apache.org/jira/browse/SOLR-14578 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: AutoScaling Affects Versions: master (9.0) Reporter: Marcus Eagan In the autoscaling docs, the name of the names of two actions are the same and it is confusing to users. See: {code:java} { "set-trigger": { "name": ".auto_add_replicas", "event": "nodeLost, "waitFor": "5s", "enabled": true, "actions": [ { "name": "auto_add_replicas_plan", "class": "solr.AutoAddReplicasPlanAction" }, { "name": "auto_add_replicas_plan", // works?, but should be execute plan "class": "solr.ExecutePlanAction" } ] } } {code} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org