Unfortunately, I think SolrCloud / cluster mode is less easy to use than standalone mode for the developer experience locally. The main pain point is the ease of modifying configuration. In standalone, I go edit some configs using a text editor, then hit "reload" on the core. Presto. With the cluster mode I need to also upload the config -- a CLI command but still awkward. Something to remember to type, something to forget. An alternative path is using Solr config APIs to do the manipulations, but frankly that's only useful for automation. It's painful to do this ad-hoc with looking up the documentation and trial & error, etc. I wish "managed" schema was not the default; I've never used in on my Solr projects.
Some ideas: * Add a config file editor to Solr. Not sure if our APIs are sufficient here; don't want to add another security risk. * Add a config path watcher / uploader script that automatically uploads on changes to the file system at a path. * Add a new mode of configSets storage such that each node stores it locally yet also syncs a single zNode ID to trigger the watches. This might use new "file store" / "package store" implementations for the new plugins management. These might even avoid the additional collection "reload" step. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Mon, Oct 14, 2019 at 12:51 PM Doug Turnbull < dturnb...@opensourceconnections.com> wrote: > I agree very much on normalizing to one mode of running Solr > > So long as the 'cluster mode' hello world is easier than having to think a > lot about zookeeper and other hard things. One reason people use standalone > mode because it's as simple as "Point '/bin/solr' at config directory and > go". If there's just cluster mode, it all should be dead simple to help > newbies play around with Solr without thinking that hard > > -Douc > > On Mon, Oct 14, 2019 at 12:36 PM Houston Putman <houstonput...@gmail.com> > wrote: > >> Jan, >> >> I agree strongly with your last point. And in case you haven't seen it >> before, there is a solr k8s operator, with a growing community, under >> development at https://github.com/bloomberg/solr-operator. >> >> I agree that taking control of the solr docker images could be a good >> idea. That way, it could have larger involvement from the community and >> grow more organically with changes in Solr itself. >> >> - Houston >> >> On Tue, Oct 8, 2019 at 8:25 PM Noble Paul <noble.p...@gmail.com> wrote: >> >>> Why even "cluster mode" or "cloud mode"? >>> >>> Solr, by default , should use the cluster mode. So in all our >>> documentation, we should use just "Solr" and it should refer to a >>> "cluster mode of Solr" >>> >>> Wherever we don't have a "cluster mode" should be explicitly qualified >>> as "standalone Solr" >>> >>> On Wed, Oct 2, 2019 at 1:24 PM David Smiley <david.w.smi...@gmail.com> >>> wrote: >>> > >>> > I hear you and sympathize but "SolrCloud" has been used long enough >>> that I doubt the trouble is worth it. I guess that makes me "+0". That >>> said, I think it wouldn't hurt to formalize "standalone mode" as-such and >>> perhaps say more explicitly that SolrCloud == "cluster mode" even if we >>> don't eliminate SolrCloud terminology. >>> > >>> > And as SolrCloud ... errr... "cluster mode" I mean, gains in usage >>> relative to "standalone mode", perhaps we can reference SolrCloud less >>> often and sorta assume that and instead make exceptions in documentation to >>> standalone mode specifics where we call that out as such. It's a loose >>> idea; I'm don't have an example in mind. >>> > >>> > Similar to the above notion, maybe "CloudSolrClient" could be more >>> invisible without renaming it. Imagine SolrClient.createFromZooKeeper() >>> etc. static methods that instantiate CloudSolrClient by default. Just a >>> thought. >>> > >>> > ~ David Smiley >>> > Apache Lucene/Solr Search Developer >>> > http://www.linkedin.com/in/davidwsmiley >>> > >>> > >>> > On Mon, Sep 30, 2019 at 11:19 AM Shawn Heisey <apa...@elyograg.org> >>> wrote: >>> >> >>> >> On 9/30/2019 6:59 AM, Ishan Chattopadhyaya wrote: >>> >> > I propose that we rename SolrCloud mode to "cluster mode" such that >>> >> > there shall be "Apache Solr", running in either "standalone mode" or >>> >> > "cluster mode". We can effect this renaming 9.0 onwards, if we have >>> >> > consensus. >>> >> > >>> >> > I am open to any other proposal as well, so long as we drop the >>> "cloud" >>> >> > in the name. >>> >> >>> >> I see your point, but I think that "cloud" is so entrenched in the >>> >> overall consciousness of the software that changing it will not be >>> easy. >>> >> >>> >> Maybe it might be something we could accomplish slowly, over the rest >>> of >>> >> 8.0's lifetime and the entire 9.0 lifetime. Begin changing the >>> >> terminology we use in communication, start shifting documentation and >>> >> code, with a hard cutover in a later major version, perhaps 10.0 or >>> 11.0. >>> >> >>> >> The level of effort involved would be considerable, whether it happens >>> >> quickly or slowly. It might be the kind of thing we just don't want >>> to >>> >> try and do. >>> >> >>> >> I'm not opposed to the idea, and I might even be able to help, but >>> it's >>> >> going to need a lot of buy-in from those of us who work on Solr. >>> >> >>> >> Thanks, >>> >> Shawn >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >>> >>> >>> -- >>> ----------------------------------------------------- >>> Noble Paul >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> > > -- > *Doug Turnbull **| CTO* | OpenSource Connections > <http://opensourceconnections.com>, LLC | 240.476.9983 > Author: Relevant Search <http://manning.com/turnbull> > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless > of whether attachments are marked as such. >
