I like Cassandra's original suggestion: uncoordinated vs coordinated (or non-coordinated vs coordinated).
On Tue, Aug 11, 2020 at 8:19 PM Jan Høydahl <[email protected]> wrote: > Hehe, «self» can be self as in user or self as in Solr :) > > Legacy feels like something that is going away, and so far the > «standalone» mode is not going anywhere. > Cassandra, feel free to propose what is your best shot and then I don’t > think we need a poll for it, but suffice a bunch of +1 on this thread. > > Managed Cluster vs Non-managed Cluster? > Managed Cluster vs User Managed Cluster? > > Jan > > 11. aug. 2020 kl. 16:21 skrev Cassandra Targett <[email protected]>: > > OK, fair point about self-managed. But I object to "leaving it" as Legacy, > as I've previously explained (I put that in quotes because it’s not always > called that at all - it has at least 3 names right now). > > The reality is someone can come up with an objection to every single > possibility. Someday we have to live with something that’s good enough and > move forward, or we’ll end up just living with the total mash of things we > have today. Which maybe is fine with everyone. > > I’ve tried to put real mental work into thinking about a good name, and > have tried to compromise based on feedback. At this point, though, unless > someone else comes up with something I’m likely done here. We’ll just > “leave it” all as it is now. > > Cassandra > On Aug 11, 2020, 9:11 AM -0500, Ishan Chattopadhyaya < > [email protected]>, wrote: > > I object to "self managed". It gives the impression that Solr manages > itself, whereas it is the other way around: users need to manage the > standalone mode with lots of manual effort, as opposed to SolrCloud which > is in spirit self managed (solr manages itself using zk). > > I'm +1 with Legacy replication and SolrCloud replication for now. Later, > we can get rid of "SolrCloud" and call it something else. Also, once > SolrCloud is stable enough, we can get rid of legacy mode altogether. We > can discuss that elsewhere. > > On Tue, 11 Aug, 2020, 7:16 pm Cassandra Targett, <[email protected]> > wrote: > >> I don’t feel there is a consensus for me to move forward confidently, but >> the docs need to be fixed before 8.7. I’ve thought about Ilan’s suggestion, >> and like calling the non-SolrCloud cluster “self-managed”. It avoids the >> currently awkward phrasing and any misinterpretation of my original >> suggestion with clumsiness as Gus pointed out. Can everyone live with that? >> >> If so, that leaves what we might eventually call SolrCloud is the >> remaining sticking point. It’s not a problem that needs to be solved today >> as the term isn’t going anywhere yet since there aren’t any patches or PRs >> to change it at a code level. >> >> Barring further objections, then, I think I will go ahead with mostly >> leaving “SolrCloud” as it is, and replacing/modifying “Legacy Scaling”, >> “leader/follower mode”, some cases of “Standalone mode”, and similar >> constructions with “Self-Managed Mode” or “Self-Managed Cluster”, etc., as >> appropriate. >> >> Cassandra >> On Aug 7, 2020, 9:05 AM -0500, Cassandra Targett <[email protected]>, >> wrote: >> >> The suggestion to use “managed” and maybe “self-managed” is an >> interesting one. Do you think it’s possible some might confuse that with >> the other ways we use managed - like the “managed-schema”, and “managed >> resources” (synonyms and stop words)? Neither of those are >> cluster-specific, and I wonder if the overlap in terminology would cause >> them to be conflated. >> >> Cassandra >> On Aug 6, 2020, 10:51 AM -0500, Ilan Ginzburg <[email protected]>, >> wrote: >> >> Both "legacy" and "SolrCloud" clusters are search server clusters. Seen >> from far enough, they look the same. >> >> In "legacy" the management code is elsewhere (developed by the client >> operating the cluster, running on other machines using a diferent logic and >> potentially another DB than Zookeeper) whereas in "SolrCloud" the >> management code is embedded in the search server(s) code and it happens >> that (currently) this code relies on Zookeeper. >> >> I see SolrCloud as a "managed cluster" vs. legacy that would be "Self >> managed" by the client, or "U manage" (non managed when looking at it from >> the Solr codebase perspective). >> >> Same idea as coordinated vs uncoordinated basically. I don't know why but >> I prefer "managed". >> >> Ilan >> >> On Thu, Aug 6, 2020 at 5:49 PM Cassandra Targett <[email protected]> >> wrote: >> >>> On Aug 6, 2020, 10:22 AM -0500, Gus Heck <[email protected]>, wrote: >>> >>> WRT the name "uncoordinated mode" I fear it could be read (or even >>> become known as) as "clumsy mode" which is humorous but possibly not what >>> we're going for :) >>> >>> >>> I had also considered “non-coordinated”, and prefer it but couldn’t >>> articulate why. The association of “uncoordinated" with clumsiness might be >>> what was bugging me. >>> >>> I'd perhaps suggest Cluster mode for SolrCloud though I'm not entirely >>> sure if Legacy Solr (in curren parlance) is not a "cluster" too, cluster >>> being a somewhat vague term. However Clustered Mode and Legacy Mode seem >>> more on target. I think "Legacy" could be changed since we're not really >>> planning on abandoning it (are we?), but >>> >>> >>> One can have a cluster and not run SolrCloud. I think from an operations >>> perspective, several servers all running Solr is considered a cluster, no >>> matter what tools are being used to get them to talk to each other. >>> >>> I think “Legacy” (also used today already in some contexts) is >>> problematic because there aren’t plans to abandon it. Also “Legacy >>> replication” is pretty close to exactly what PULL replicas use to poll >>> leaders and pull new index segments when needed. IOW, it’s not “legacy”, >>> it’s very actively being used in a growing number of clusters. That might >>> be an implementation detail users aren’t aware of, but I feel the term is >>> really lacking mostly in that it just doesn’t say anything besides “it’s >>> older”. >>> >>> the adjective there SHOULD communicate reduced functionality because >>> there are plenty of features that are cloud (cluster) only. >>> >>> >>> In my view, the reduced functionality of non-SolrCloud clusters is >>> mostly around coordination of requests, leader election, configs, and other >>> similar automated activities one does manually otherwise. So, I feel that >>> sort of proves my point - a word that conveys lack of coordination is a >>> good option for what it’s called. If there is a better antonym for >>> “coordinated”, I’m all for considering it but haven’t yet been able to >>> think of/find one. >>> >>> I think it’s important to think about what differentiates the two ways >>> of managing a Solr cluster and derive the naming from that. What features >>> of SolrCloud don’t exist in the non-SolrCloud approach? What words help us >>> generalize those gaps and can any of them be an appropriate name? >>> >>> >>> -Gus >>> >>> >>> On Thu, Aug 6, 2020 at 10:27 AM Cassandra Targett <[email protected]> >>> wrote: >>> >>> The work in SOLR-14702 has left us with some awkward phrasing (which is >>> still better than what it was) around non-SolrCloud clusters that I've >>> offered to help fix. >>> >>> >>> I think we've struggled for years to find a good name for non-SolrCloud >>> clusters and we've used a number of variations: "legacy replication" (which >>> it isn't, since PULL replicas use the same thing), "Standalone mode" (which >>> it isn't because it's a cluster), now "leader/follower mode" (which could >>> be confusing because SolrCloud has leaders). >>> >>> >>> Yesterday I thought about what really differentiates a SolrCloud cluster >>> and a non-SolrCloud cluster and it occurred to me that a key difference is >>> the former is coordinated by ZooKeeper, while the latter is not. That led >>> me to think that perhaps "coordinated mode" can someday be a better >>> replacement for the term "SolrCloud", while "uncoordinated mode" could be a >>> replacement today for all these other non-SolrCloud mode variations. >>> >>> >>> I've opened https://issues.apache.org/jira/browse/SOLR-14716 and will >>> create a branch for work in progress, but before I forge too far ahead, I >>> want to draw attention to it first to give a chance for discussion so we're >>> in agreement. >>> >>> >>> Thanks, >>> >>> Cassandra >>> >>> >>> >>> -- >>> >>> http://www.needhamsoftware.com (work) >>> >>> http://www.the111shift.com (play) >>> >>> >
