Please start another thread to discuss removal of standalone mode, and stay
on-topic in this one.
> 28. jun. 2020 kl. 14:42 skrev Erick Erickson <erickerick...@gmail.com>:
>
> We need to draw a sharp distinction between standalone “going away”
> in terms of our internal code and going away in terms of the user
> experience.
>
> Usually when we’re talking about standalone going a way, it’s the
> former. The assumption is that we’ll use an embedded ZK that
> fires up automatically so Solr behaves very similarly to how it
> behaves in the current standalone mode just without all the
> if (zkHost == null) do_something else do_something_else
>
> I wonder it the slickest way to use embedded ZK would be to
> populate the embedded ZK during core discovery
>
> Erick
>
>
>
>> On Jun 28, 2020, at 6:40 AM, Ishan Chattopadhyaya
>> <ichattopadhy...@gmail.com> wrote:
>>
>> Cost of maintaining feature parity across the two modes is an overhead.
>> Security plugins, package manager (that doesn't work in standalone), UI,
>> etc. Our codebase is littered with checks to ascertain if we're zkAware.
>> There are massive benefits to maintainability if standalone mode were to go
>> away. Of course, provided all usecases that could be solved using
>> standalone can also be solved using SolrCloud. At that point, I'd love for
>> us to get rid of the term "SolrCloud".
>>
>> On Sun, 28 Jun, 2020, 3:59 pm Ishan Chattopadhyaya, <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> I would like to know under which situations (except for the various bugs
>>> that will be fixed eventually) would a SolrCloud solution not suffice.
>>> AFAICT, pull replicas and tlog replicas can provide similar replication
>>> strategies commonly used with standalone Solr. I understand that running ZK
>>> is an overhead and SolrCloud isn't best written when it comes to handling
>>> ZK, but that can be improved.
>>>
>>> And for those users who just want a single node Solr, they can just start
>>> Solr with embedded ZK. It won't practically make difference.
>>>
>>> On Sun, 28 Jun, 2020, 3:45 pm Ilan Ginzburg, <ilans...@gmail.com> wrote:
>>>
>>>> I disagree Ishan. We shouldn't get rid of standalone mode.
>>>> I see three layers in Solr:
>>>>
>>>> 1. Lucene (the actual search libraries)
>>>> 2. The server infra ("standalone Solr" basically)
>>>> 3. Cluster management (SolrCloud)
>>>>
>>>> There's value in using lower layers without higher ones.
>>>> SolrCloud is a good solution for some use cases but there are others that
>>>> need a search server and for which SolrCloud is not a good fit and will
>>>> likely never be. If standalone mode is no longer available, such use cases
>>>> will have to turn to something other than Solr (or fork and go their own
>>>> way).
>>>>
>>>> Ilan
>>>>
>>>> On Sat, Jun 27, 2020 at 9:39 PM Ishan Chattopadhyaya <
>>>> ichattopadhy...@gmail.com> wrote:
>>>>
>>>>> Rather than getting rid of the terminology, we should get rid of the
>>>>> standalone mode Solr altogether. I totally understand that SolrCloud is
>>>>> broken in many ways today, but we should attempt to fix it and have it
>>>> as
>>>>> the only mode in Solr.
>>>>>
>>>>> On Wed, 24 Jun, 2020, 8:17 pm Mike Drob, <md...@apache.org> wrote:
>>>>>
>>>>>> Brend,
>>>>>>
>>>>>> I appreciate that you are trying to examine this issue from multiple
>>>>> sides
>>>>>> and consider future implications, but I don’t think that is a stirring
>>>>>> argument. By analogy, if we are out of eggs and my wife asks me to go
>>>> to
>>>>>> the store to get some, refusing to do so on the basis that she might
>>>> call
>>>>>> me while I’m there and also ask me to get milk would not be
>>>> reasonable.
>>>>>>
>>>>>> What will come next may be an interesting question philosophically,
>>>> but
>>>>> we
>>>>>> are not discussing abstract concepts here. There is a concrete issue
>>>>>> identified, and we’re soliciting input in how best to address it.
>>>>>>
>>>>>> Thank you for the suggestion of "guide/follower"
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> On Wed, Jun 24, 2020 at 6:30 AM Bernd Fehling <
>>>>>> bernd.fehl...@uni-bielefeld.de> wrote:
>>>>>>
>>>>>>> I'm following this thread now for a while and I can understand
>>>>>>> the wish to change some naming/wording/speech in one or the other
>>>>>>> programs but I always get back to the one question:
>>>>>>> "Is it the weapon which kills people or the hand controlled by
>>>>>>> the mind which fires the weapon?"
>>>>>>>
>>>>>>> The thread started with slave - slavery, then turned over to master
>>>>>>> and followed by leader (for me as a german... you know).
>>>>>>> What will come next?
>>>>>>>
>>>>>>> And more over, we now discuss about changes in the source code and
>>>>>>> due to this there need to be changes to the documentation.
>>>>>>> What about the books people wrote about this programs and source
>>>> code,
>>>>>>> should we force this authors to rewrite their books?
>>>>>>> May be we should file a request to all web search engines to reject
>>>>>>> all stored content about these "banned" words?
>>>>>>> And contact all web hosters about providing bad content.
>>>>>>>
>>>>>>> To sum things up, within my 40 years of computer science and writing
>>>>>>> programs I have never had a nanosecond any thoughts about words
>>>>>>> like master, slave, leader, ... other than thinking about computers
>>>>>>> and programming.
>>>>>>>
>>>>>>> Just my 2 cents.
>>>>>>>
>>>>>>> For what it is worth, I tend to guide/follower if there "must be"
>>>> any
>>>>>>> changes.
>>>>>>>
>>>>>>> Bernd
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
