You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SolrCollection and SolrCollectionAlias CRDs are nice constructs that allow users to create Solr collections and aliases through Kubernetes APIs (and tools, such as kubectl).
The issue with having these is that the internal state of Solr is replicated in two places, EtcD (where the API Server saves all Kubernetes resources) and Zookeeper (where Solr keeps its internal state). This naturally leads to the problem of how do we keep these two sources of information up-to-date. One solution would be to use SolrJ APIs to watch Zookeeper for changes to the state and make those updates in the API Server. However if a change happens in the API Server and Zookeeper at the same time, which should we prefer? Also since the Solr Operator is written in Go, these convenient SolrJ APIs are not available to us.
In general, Solr has nice HTTP APIs that allow for management of collections and aliases. The Kube CRD representations of them only provide a wrapper for users to interact, they provide no runtime benefits within the system.
For this reason the Apache Lucene (and Solr) PMC has decided to remove these two CRDs from the official repo and allow the community to take control of them. They would still be able to interact with the official Apache Solr CRDs in the same way, however the controllers would live in a separate binary and would be released under in a different cadence. The v0.2.8 release will be the last release in which these CRDs will be monitored by the Solr Operator.
We will provide documentation in the upgrade instructions on how to safely remove these CRDs or migrate them to their new locations when upgrading to v0.3.0.
CRDs that deal with runtime of Solr and its peripheral systems will continue to be official Apache Solr CRDS and be supported fully. Currently this includes the SolrCloud, SolrPrometheusExporter and SolrBackup CRDS.
The text was updated successfully, but these errors were encountered:
I can help with this. I was thinking we could start a Terraform Provider and automate resource management for Collections, Alias, and Config Sets with it. If users of lucene-solr-operator also use Terraform as part of there infra automation tool set and like this idea, let me know. 👍
The
SolrCollection
andSolrCollectionAlias
CRDs are nice constructs that allow users to create Solr collections and aliases through Kubernetes APIs (and tools, such as kubectl).The issue with having these is that the internal state of Solr is replicated in two places, EtcD (where the API Server saves all Kubernetes resources) and Zookeeper (where Solr keeps its internal state). This naturally leads to the problem of how do we keep these two sources of information up-to-date. One solution would be to use SolrJ APIs to watch Zookeeper for changes to the state and make those updates in the API Server. However if a change happens in the API Server and Zookeeper at the same time, which should we prefer? Also since the Solr Operator is written in Go, these convenient SolrJ APIs are not available to us.
In general, Solr has nice HTTP APIs that allow for management of collections and aliases. The Kube CRD representations of them only provide a wrapper for users to interact, they provide no runtime benefits within the system.
For this reason the Apache Lucene (and Solr) PMC has decided to remove these two CRDs from the official repo and allow the community to take control of them. They would still be able to interact with the official Apache Solr CRDs in the same way, however the controllers would live in a separate binary and would be released under in a different cadence.
The
v0.2.8
release will be the last release in which these CRDs will be monitored by the Solr Operator.We will provide documentation in the upgrade instructions on how to safely remove these CRDs or migrate them to their new locations when upgrading to
v0.3.0
.CRDs that deal with runtime of Solr and its peripheral systems will continue to be official Apache Solr CRDS and be supported fully. Currently this includes the
SolrCloud
,SolrPrometheusExporter
andSolrBackup
CRDS.The text was updated successfully, but these errors were encountered: