You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Ishan Chattopadhyaya <ic...@gmail.com> on 2019/09/30 12:59:28 UTC
Renaming SolrCloud
Hi,
I think some of us feel that
SolrCloud or "cloud mode" etc. are misnomers. This name sometimes trips up
many adopters.
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.
Thoughts, please?
Regards,
Ishan
Re: Renaming SolrCloud
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Mon, Sep 30, 2019 at 3:59 PM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:
> Hi,
> I think some of us feel that
> SolrCloud or "cloud mode" etc. are misnomers. This name sometimes trips up
> many adopters.
>
> 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.
>
+1 on this proposal !
>
>
> I am open to any other proposal as well, so long as we drop the "cloud"
> in the name.
> Thoughts, please?
> Regards,
> Ishan
>
Re: Renaming SolrCloud
Posted by Jan Høydahl <ja...@cominvent.com>.
+1 to adapting all our docs to make cluster mode the preferred/default and “hide” the standalone use cases more. We could also redefine -c in start script to mean “cluster”?
Instead of getting rid of the SolrCloud term, why not strive for making Solr more “cloud native”, and thus live up to the expectation new users may have? That may mean that we as a project take ownership of our Docker images, help develop a k8s operator, etc.
Jan Høydahl
> 2. okt. 2019 kl. 06:24 skrev David Smiley <da...@gmail.com>:
>
>
> 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 <ap...@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
Re: Renaming SolrCloud
Posted by Malcolm Upayavira Holmes <uv...@odoko.co.uk>.
Solr can run Zookeeper embedded. Just make the 'standalone' version run a Zookeeper, then you can deprecate the standalone mode entirely.
Also, given that installing ZooKeeper is a pain, and that Solr has the embedded ability to run ZooKeeper, it always seemed a good idea to me to have the option to run ZK from within the Solr codebase, e.g:
solr zookeeper start --various=options
Would start a Zookeeper instance, and make one less thing to go download.
Upayavira
On Mon, 14 Oct 2019, at 5:40 PM, Doug Turnbull 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 <ho...@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 <no...@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 <da...@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 <ap...@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-unsubscribe@lucene.apache.org
>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>>
>>>
>>> --
>>> -----------------------------------------------------
>>> Noble Paul
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@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.
Re: Renaming SolrCloud
Posted by Bram Van Dam <br...@intix.eu>.
On 20/10/2019 01:32, Noble Paul wrote:
> A standalone mode should be nothing but a SolrCloud setup with an
> embedded ZK and a single node.
From an operations point of view, I disagree. ZK is another process to
monitor, another process which can fail, another process which exposes
various security concerns. Additionally, ZK's Administrator Guide still
insists that its transaction log should be on a separate disk ("A
dedicated partition is not enough"), which is quite frankly a pain in
the arse for smaller setups. I'm not sure whether it's all that
important in standalone mode, but it's certainly something to consider.
- Bram
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Renaming SolrCloud
Posted by Noble Paul <no...@gmail.com>.
A standalone mode should be nothing but a SolrCloud setup with an
embedded ZK and a single node.
If users want to edit config files they can still do it . People edit
config files all the time in SolrCloud today. Directly editing files
on a filesystem cannot be a requirement that keeps as from moving on
to a unified model
On Fri, Oct 18, 2019 at 4:36 AM Shawn Heisey <ap...@elyograg.org> wrote:
>
> On 10/17/2019 10:58 AM, David Smiley wrote:
> > 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.
>
> It would be VERY useful to have this. It should require explicit admin
> action to enable -- not enabled by default, or it will get tagged as a
> security issue. And I think it should work in both cloud and standalone.
>
> In a similar way, it would be really nice if there was a way to
> edit/add/delete anything in the ZK database right in the admin UI. It
> will need a caution note saying that doing so can be dangerous, and
> similar to config editing, should not be enabled by default.
>
> > * 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.
>
> If it can be made bulletproof, I'm not opposed. Maybe some kind of
> mirroring of configsets in ZK and on every node. By paying attention to
> modification times, automatic synchronization could be accomplished --
> so when a file is changed in one place, whether that is in a node
> configset directory or in ZK, it gets updated in all other locations.
> My worry with this idea is that it will be difficult to avoid the
> implementation being brittle ... but if it's very carefully done, that
> shouldn't be a problem in practice.
>
> I wonder whether deletions could be handled. Probably need the ability
> to designate one location as the canonical resource if we want that to work.
>
> > These might even avoid the additional collection "reload" step.
>
> I don't know that I like the idea of automated collection reloads, at
> least by default. Somebody might want to edit a configset for an
> upcoming change, but wait two hours before reloading linked collections
> and activating the change. Having an option to enable automatic reloads
> if the admin chooses sounds good.
>
> Thanks,
> Shawn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
--
-----------------------------------------------------
Noble Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Renaming SolrCloud
Posted by Shawn Heisey <ap...@elyograg.org>.
On 10/17/2019 10:58 AM, David Smiley wrote:
> 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.
It would be VERY useful to have this. It should require explicit admin
action to enable -- not enabled by default, or it will get tagged as a
security issue. And I think it should work in both cloud and standalone.
In a similar way, it would be really nice if there was a way to
edit/add/delete anything in the ZK database right in the admin UI. It
will need a caution note saying that doing so can be dangerous, and
similar to config editing, should not be enabled by default.
> * 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.
If it can be made bulletproof, I'm not opposed. Maybe some kind of
mirroring of configsets in ZK and on every node. By paying attention to
modification times, automatic synchronization could be accomplished --
so when a file is changed in one place, whether that is in a node
configset directory or in ZK, it gets updated in all other locations.
My worry with this idea is that it will be difficult to avoid the
implementation being brittle ... but if it's very carefully done, that
shouldn't be a problem in practice.
I wonder whether deletions could be handled. Probably need the ability
to designate one location as the canonical resource if we want that to work.
> These might even avoid the additional collection "reload" step.
I don't know that I like the idea of automated collection reloads, at
least by default. Somebody might want to edit a configset for an
upcoming change, but wait two hours before reloading linked collections
and activating the change. Having an option to enable automatic reloads
if the admin chooses sounds good.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Renaming SolrCloud
Posted by David Smiley <da...@gmail.com>.
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 <
dturnbull@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 <ho...@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 <no...@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 <da...@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 <ap...@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-unsubscribe@lucene.apache.org
>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>>
>>>
>>> --
>>> -----------------------------------------------------
>>> Noble Paul
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@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.
>
Re: Renaming SolrCloud
Posted by Doug Turnbull <dt...@opensourceconnections.com>.
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 <ho...@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 <no...@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 <da...@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 <ap...@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-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@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.
Re: Renaming SolrCloud
Posted by Houston Putman <ho...@gmail.com>.
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 <no...@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 <da...@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 <ap...@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-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Renaming SolrCloud
Posted by Noble Paul <no...@gmail.com>.
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 <da...@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 <ap...@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
--
-----------------------------------------------------
Noble Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Renaming SolrCloud
Posted by David Smiley <da...@gmail.com>.
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 <ap...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Renaming SolrCloud
Posted by Shawn Heisey <ap...@elyograg.org>.
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org