Houston Putman created SOLR-16740:
-------------------------------------
Summary: Create a KubernetesConfigSetService
Key: SOLR-16740
URL: https://issues.apache.org/jira/browse/SOLR-16740
Project: Solr
Issue Type: Sub-task
Security Level: Public (Default Security Level. Issues are Public)
Components: module - kubernetes
Reporter: Houston Putman
Many users who run Solr on Kubernetes ask for a more kubernetes-native way of
managing ConfigSets. A common suggestion is to allow ConfigSets to be managed
via [ConfigMaps|https://kubernetes.io/docs/concepts/configuration/configmap/].
The idea is that Kubernetes acts as a distributed file store, much like
Zookeeper does, through the API Server (which is backed by EtcD). The
ConfigSetService is already an interface that has multiple implementations
(Zookeeper and FileSystem). The KubernetesConfigSetService would connect to the
Kubernetes API Server for the cluster that Solr is running in, and
watch/retrieve/update/create ConfigMaps for various ConfigSet operations.
There is actually no need to interact with the Solr Operator at all for the
KubernetesConfigSetService, since it will be watching on ConfigMap labels,
which will be set by the user. If the SolrCloud CRD also included which
configMaps it should manage, then user operations within the cluster
(create/delete a configSet) will make this information out-of-date. Therefore
we will keep things simple and use one source of truth for what configMaps
belong to a SolrCloud (which is the ConfigMap's labels).
The Solr Operator has stayed out of managing ConfigSets because there is always
concern around having 2 sources of truth (Kubernetes and Zookeeper). With this
implementation, no information about the configSet would be stored in
Zookeeper, so users would be safe to use ConfigMaps to fully manage their
ConfigSets.
Kubernetes APIs do allow for watching objects (such as ConfigMaps), however for
this application it's not really necessary since Solr does not watch ConfigSets
in Zookeeper. They are updated on reload commands.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
