[
https://issues.apache.org/jira/browse/SOLR-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477256#comment-16477256
]
Jan Høydahl commented on SOLR-6734:
-----------------------------------
I'm arguing back and forth with myself on this. While it gives easier cluster
setups since we ship ZK, it also re-invents some of the orchestration tasks
that frameworks like Kubernetes, Swarm & Mesos were built to handle. Like
"Where do my zookeepers run?" and "Node A with ZK died, should we start it on
node B?".
I also realise that most people will not consider K8s for small clusters due to
the (current) complexity of installing and overhead, but looking 3-5 years into
the crystal ball I can see more and more users wanting to run their search
cluster containerized and freely choose whether to deploy in a public cloud, a
private cloud or on-premise. Also in that time frame K8s will probably be
mature for small local DC installs, and your average hosting provider will
offer container services.
So my question is whether it makes sense to instead focus our efforts into
lowering the bar for running Solr on Kubernetes, and aim to promote that as an
officially supported environment and later perhaps the recommended one? This
could translate into developing a high-quality and feature rich [Kubernetes
Operator|https://coreos.com/operators/] for Solr. An Operator is a program that
knows the application well and can support high-level cluster operations such
as "install a 3x2 node cluster with 3 ZKs", or "do a rolling upgrade from SolrX
to SolrY", or "Spin up more nodes / containers / pods if Solr' Metric X is
above threshold Y for more than Z minutes".
> Standalone solr as *two* applications -- Solr and a controlling agent
> ---------------------------------------------------------------------
>
> Key: SOLR-6734
> URL: https://issues.apache.org/jira/browse/SOLR-6734
> Project: Solr
> Issue Type: Sub-task
> Reporter: Shawn Heisey
> Priority: Major
>
> In a message to the dev list outlining reasons to switch from a webapp to a
> standalone app, Mark Miller included the idea of making Solr into two
> applications, rather than just one. There would be Solr itself, and an agent
> to control Solr.
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201305.mbox/%3C807476C6-E4C3-4E7E-9F67-2BECB63990DE%40gmail.com%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
