This is an automated email from the ASF dual-hosted git repository.
houston pushed a commit to branch gh-pages
in repository https://gitbox.apache.org/repos/asf/solr-operator.git
The following commit(s) were added to refs/heads/gh-pages by this push:
new 7a053df Upgrade documentation for v0.4.0 release
7a053df is described below
commit 7a053df2e5034a56be629ef822ae97a5b5dcbc58
Author: Houston Putman <hous...@apache.org>
AuthorDate: Mon Sep 13 14:47:13 2021 -0400
Upgrade documentation for v0.4.0 release
---
NOTICE | 2 +-
README.md | 19 ++--
docs/development.md | 2 +-
docs/local_tutorial.md | 50 +++------
docs/running-the-operator.md | 9 +-
docs/solr-cloud/solr-cloud-crd.md | 180 +++++++++++++++++++++++++++++---
docs/solr-prometheus-exporter/README.md | 5 +
docs/upgrade-notes.md | 50 ++++++++-
8 files changed, 246 insertions(+), 71 deletions(-)
diff --git a/NOTICE b/NOTICE
index ed2ed85..e3db3cb 100644
--- a/NOTICE
+++ b/NOTICE
@@ -38,4 +38,4 @@ Copyright (c) 2020 Dell Inc., or its subsidiaries. All Rights
Reserved.
The Zookeeper Operator is used as an optional dependency, however the
ZookeeperCluster CRD is used within the repository.
config/dependencies/zookeeper_cluster_crd.yaml
-This was taken from https://github.com/pravega/zookeeper-operator (version
v0.2.9)
\ No newline at end of file
+This was taken from https://github.com/pravega/zookeeper-operator (version
v0.2.12)
diff --git a/README.md b/README.md
index 60bc6e1..cfb76e1 100644
--- a/README.md
+++ b/README.md
@@ -3,17 +3,18 @@
[](http://www.apache.org/licenses/LICENSE-2.0.html)
[](https://artifacthub.io/packages/search?repo=apache-solr)
[](https://github.com/apache/solr-operator/commits/main)
-[](https://hub.docker.com/r/bloomberg/solr-operator/)
+[](https://hub.docker.com/r/apache/solr-operator/)
[](https://kubernetes.slack.com/messages/solr-operator)
-[![Mailing List]]
-The __Solr Operator__ manages Apache Solr Clouds within Kubernetes. It is
built on top of the [Kube
Builder](https://github.com/kubernetes-sigs/kubebuilder) framework.
+The __[Solr Operator](https://solr.apache.org/operator/)__ manages Apache Solr
Clouds within Kubernetes.
+It is built on top of the [Kube
Builder](https://github.com/kubernetes-sigs/kubebuilder) framework.
+Please visit the [official site](https://solr.apache.org/operator/) for more
information.
The project is currently in beta (`v1beta1`), and while we do not anticipate
changing the API in backwards-incompatible ways there is no such guarantee yet.
If you run into issues using the Solr Operator, please:
- Reference the [version compatibility and upgrade/deprecation
notes](#version-compatibility--upgrade-notes) provided below
-- Create a Github Issue in this repo, describing your problem with as much
detail as possible
+- Create a GitHub Issue in this repo, describing your problem with as much
detail as possible
- Reach out on our Slack channel!
Join us on the
[#solr-operator](https://kubernetes.slack.com/messages/solr-operator) channel
in the official Kubernetes slack workspace.
@@ -50,11 +51,7 @@ Example uses of each CRD have been
[provided](https://apache.github.io/solr-oper
Make sure to check the [Solr Operator Upgrade notes](docs/upgrade-notes.md),
before upgrading the Solr Operator or CRDs in your Kubernetes cluster.
-### Compatibility with Kubernetes Versions
-
-#### Fully Compatible - v1.16+
-
-If you require compatibility with previous versions, please install version
`v0.2.6` of the Solr Operator.
+This page also contains [Version Compatibility
Matrixes](docs/upgrade-notes.md#version-compatibility-matrixes), which detail
the compatible Solr versions and Kubernetes versions for each release of the
Solr Operator.
## Contributions
@@ -65,7 +62,7 @@ Have you had a good experience with the **Solr Operator**?
Why not share some lo
We welcome issue reports [here](../../issues); be sure to choose the proper
issue template for your issue, so that we can be sure you're providing the
necessary information.
Before submitting a PR, please be sure to run `make prepare` before committing.
-Otherwise the github checks are likely to fail.
+Otherwise the GitHub checks are likely to fail.
## License
@@ -94,4 +91,4 @@ we've had an opportunity to review and address them.
## Acknowledgements
The Solr Operator was donated to Apache Solr by Bloomberg, after the v0.2.8
release.
-Many thanks to their contributions over the years!
\ No newline at end of file
+Many thanks to their contributions over the years!
diff --git a/docs/development.md b/docs/development.md
index b1ac155..6fe577a 100644
--- a/docs/development.md
+++ b/docs/development.md
@@ -24,7 +24,7 @@ It is optional, however, as described in the [Zookeeper
Reference](solr-cloud/so
```bash
helm repo add pravega https://charts.pravega.io
-helm install zookeeper-operator pravega/zookeeper-operator --version 0.2.9
+helm install zookeeper-operator pravega/zookeeper-operator --version 0.2.12
```
Install necessary dependencies for building and deploying the operator.
diff --git a/docs/local_tutorial.md b/docs/local_tutorial.md
index d4fc268..1620dc6 100644
--- a/docs/local_tutorial.md
+++ b/docs/local_tutorial.md
@@ -73,9 +73,9 @@ This will install the [Zookeeper
Operator](https://github.com/pravega/zookeeper-
```bash
# Install the Solr & Zookeeper CRDs
-$ kubectl create -f
https://solr.apache.org/operator/downloads/crds/v0.3.0/all-with-dependencies.yaml
+$ kubectl create -f
https://solr.apache.org/operator/downloads/crds/v0.4.0/all-with-dependencies.yaml
# Install the Solr operator and Zookeeper Operator
-$ helm install solr-operator apache-solr/solr-operator --version 0.3.0
+$ helm install solr-operator apache-solr/solr-operator --version 0.4.0
```
_Note that the Helm chart version does not contain a `v` prefix, which the
downloads version does. The Helm chart version is the only part of the Solr
Operator release that does not use the `v` prefix._
@@ -105,23 +105,13 @@ After inspecting the status of you Kube cluster, you
should see a deployment for
To start a Solr Cloud cluster, we will create a yaml that will tell the Solr
Operator what version of Solr Cloud to run, and how many nodes, with how much
memory etc.
```bash
-# Create a a 3-node cluster v8.3 with 300m Heap each:
-cat <<EOF | kubectl apply -f -
-apiVersion: solr.apache.org/v1beta1
-kind: SolrCloud
-metadata:
- name: example
-spec:
- replicas: 3
- solrImage:
- tag: "8.3"
- solrJavaMem: "-Xms300m -Xmx300m"
- solrAddressability:
- external:
- method: Ingress
- domainName: "ing.local.domain"
- useExternalAddress: true
-EOF
+# Create a 3-node cluster v8.3 with 300m Heap each:
+helm install example-solr apache-solr/solr --version 0.4.0 \
+ --set image.tag=8.3 \
+ --set solrOptions.javaMemory="-Xms300m -Xmx300m" \
+ --set addressability.external.method=Ingress \
+ --set addressability.external.domainName="ing.local.domain" \
+ --set addressability.external.useExternalAddress="true"
# The solr-operator has created a new resource type 'solrclouds' which we can
query
# Check the status live as the deploy happens
@@ -192,6 +182,7 @@ spec:
Make sure that you are not overwriting the `SolrCloud.Spec.replicas` field
when doing `kubectl apply`,
otherwise you will be undoing the autoscaler's work.
+By default, the helm chart does not set the `replicas` field, so it is safe to
use with the HPA.
## Upgrade to newer version
@@ -201,23 +192,10 @@ So we wish to upgrade to a newer Solr version:
# Take note of the current version, which is 8.3.1
curl -s
http://default-example-solrcloud.ing.local.domain/solr/admin/info/system | grep
solr-i
-# Update the solrCloud configuration with the new version, keeping 5 nodes
-cat <<EOF | kubectl apply -f -
-apiVersion: solr.apache.org/v1beta1
-kind: SolrCloud
-metadata:
- name: example
-spec:
- replicas: 5
- solrImage:
- tag: "8.7"
- solrJavaMem: "-Xms300m -Xmx300m"
- solrAddressability:
- external:
- method: Ingress
- domainName: "ing.local.domain"
- useExternalAddress: true
-EOF
+# Update the solrCloud configuration with the new version, keeping all
previous settings and the number of nodes set by the autoscaler.
+helm upgrade example-solr apache-solr/solr --version 0.4.0 \
+ --reuse-values \
+ --set image.tag=8.7
# Click the 'Show all details" button in Admin UI and start hitting the
"Refresh" button
# See how the operator upgrades one pod at a time. Solr version is in the
'node' column
diff --git a/docs/running-the-operator.md b/docs/running-the-operator.md
index 3effe2e..855981c 100644
--- a/docs/running-the-operator.md
+++ b/docs/running-the-operator.md
@@ -21,8 +21,8 @@ Next, install the Solr Operator chart. Note this is using
Helm v3, use the offic
This will install the [Zookeeper
Operator](https://github.com/pravega/zookeeper-operator) by default.
```bash
-$ kubectl create -f
https://solr.apache.org/operator/downloads/crds/v0.3.0/all-with-dependencies.yaml
-$ helm install solr-operator apache-solr/solr-operator --version 0.3.0
+$ kubectl create -f
https://solr.apache.org/operator/downloads/crds/v0.4.0/all-with-dependencies.yaml
+$ helm install solr-operator apache-solr/solr-operator --version 0.4.0
```
_Note that the Helm chart version does not contain a `v` prefix, which the
downloads version does. The Helm chart version is the only part of the Solr
Operator release that does not use the `v` prefix._
@@ -140,4 +140,7 @@ The CA certificate needs to be stored in Kubernetes secret
in PEM format and pro
```
In most cases, you'll also want to configure the operator with
`mTLS.insecureSkipVerify=true` (the default) as you'll want the operator to
skip hostname verification for Solr pods.
-Setting `mTLS.insecureSkipVerify` to `false` means the operator will enforce
hostname verification for the certificate provided by Solr pods.
\ No newline at end of file
+Setting `mTLS.insecureSkipVerify` to `false` means the operator will enforce
hostname verification for the certificate provided by Solr pods.
+
+By default, the operator watches for updates to the mTLS client certificate
(mounted from the `mTLS.clientCertSecret` secret) and then refreshes the HTTP
client to use the updated certificate.
+To disable this behavior, configure the operator using: `--set
mTLS.watchForUpdates=false`.
\ No newline at end of file
diff --git a/docs/solr-cloud/solr-cloud-crd.md
b/docs/solr-cloud/solr-cloud-crd.md
index da7bcc3..e9b42cc 100644
--- a/docs/solr-cloud/solr-cloud-crd.md
+++ b/docs/solr-cloud/solr-cloud-crd.md
@@ -28,8 +28,12 @@ These options can be found in `SolrCloud.spec.dataStorage`
Note: This template cannot be changed unless the SolrCloud is deleted and
recreated.
This is a [limitation of StatefulSets and PVCs in
Kubernetes](https://github.com/kubernetes/enhancements/issues/661).
- **`ephemeral`**
+
+ There are two types of ephemeral volumes that can be specified.
+ Both are optional, and if none are specified then an empty `emptyDir` volume
source is used.
+ If both are specified then the `hostPath` volume source will take precedence.
- **`emptyDir`** - An [`emptyDir` volume
source](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) that
describes the desired emptyDir volume to use in each SolrCloud pod to store
data.
- This option is optional, and if not provided an empty `emptyDir` volume
source will be used.
+ - **`hostPath`** - A [`hostPath` volume
source](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath) that
describes the desired hostPath volume to use in each SolrCloud pod to store
data.
- **`backupRestoreOptions`** (Required for integration with
[`SolrBackups`](../solr-backup/README.md))
- **`volume`** - This is a [volume
source](https://kubernetes.io/docs/concepts/storage/volumes/), that supports
`ReadWriteMany` access.
@@ -54,7 +58,9 @@ Under `SolrCloud.Spec.updateStrategy`:
- **`maxPodsUnavailable`** - (Defaults to `"25%"`) The number of Solr pods
in a Solr Cloud that are allowed to be unavailable during the rolling restart.
More pods may become unavailable during the restart, however the Solr
Operator will not kill pods if the limit has already been reached.
- **`maxShardReplicasUnavailable`** - (Defaults to `1`) The number of
replicas for each shard allowed to be unavailable during the restart.
-
+- **`restartSchedule`** - A [CRON](https://en.wikipedia.org/wiki/Cron)
schedule for automatically restarting the Solr Cloud.
+ [Multiple CRON
syntaxes](https://pkg.go.dev/github.com/robfig/cron/v3?utm_source=godoc#hdr-CRON_Expression_Format)
are supported, such as intervals (e.g. `@every 10h`) or predefined schedules
(e.g. `@yearly`, `@weekly`, etc.).
+
**Note:** Both `maxPodsUnavailable` and `maxShardReplicasUnavailable` are
intOrString fields. So either an int or string can be provided for the field.
- **int** - The parameter is treated as an absolute value, unless the value is
<= 0 which is interpreted as unlimited.
- **string** - Only percentage string values (`"0%"` - `"100%"`) are accepted,
all other values will be ignored.
@@ -80,7 +86,7 @@ Under `SolrCloud.Spec.solrAddressability`:
- **`useExternalAddress`** - Use the external address to advertise the
SolrNode. If a domain name is required for the chosen external `method`, then
the one provided in `domainName` will be used.
- **`hideCommon`** - Do not externally expose the common service (one
endpoint for all solr nodes).
- **`hideNodes`** - Do not externally expose each node. (This cannot be set
to `true` if the cloud is running across multiple kubernetes clusters)
- - **`nodePortOverride`** - Make the Node Service(s) override the podPort.
This is only available for the `Ingress` external method. If `hideNodes` is set
to `true`, then this option is ignored. If provided, his port will be used to
advertise the Solr Node. \
+ - **`nodePortOverride`** - Make the Node Service(s) override the podPort.
This is only available for the `Ingress` external method. If `hideNodes` is set
to `true`, then this option is ignored. If provided, this port will be used to
advertise the Solr Node. \
If `method: Ingress` and `hideNodes: false`, then this value defaults to
`80` since that is the default port that ingress controllers listen on.
**Note:** Unless both `external.method=Ingress` and
`external.hideNodes=false`, a headless service will be used to make each Solr
Node in the statefulSet addressable.
@@ -142,6 +148,27 @@ each solrCloud that has this option specified.
The startup parameter `zookeeper-operator` must be provided on startup of the
solr-operator for this parameter to be available.
+#### Zookeeper Storage Options
+_Since v0.4.0_
+
+The Zookeeper Operator allows for both ephemeral and persistent storage, and
the Solr Operator supports both as of `v0.4.0`.
+
+```yaml
+spec:
+ zookeeperRef:
+ provided:
+ ephemeral:
+ emptydirvolumesource: {}
+ persistence:
+ reclaimPolicy: "Retain" # Either Retain or Delete
+ spec: {} # PVC Spec for the Zookeeper volumes
+```
+
+By default, if you do not provide either `ephemeral` or `persistence`, the
Solr Operator will default to the type of storage you are using for your Solr
pods.
+
+However, if you provide either object above, even if the object is empty, that
storage type will be used for the created Zookeeper pods.
+If both `ephemeral` and `persistence` is provided, then `persistence` is
preferred.
+
#### ACLs for Provided Ensembles
_Since v0.3.0_
@@ -280,21 +307,22 @@ data:
## Enable TLS Between Solr Pods
_Since v0.3.0_
-A common approach to securing traffic to your Solr cluster is to perform **TLS
termination** at the Ingress and leave all traffic between Solr pods
un-encrypted.
+A common approach to securing traffic to your Solr cluster is to perform
[**TLS termination** at the Ingress](#enable-ingress-tls-termination) and leave
all traffic between Solr pods un-encrypted.
However, depending on how you expose Solr on your network, you may also want
to encrypt traffic between Solr pods.
The Solr operator provides **optional** configuration settings to enable TLS
for encrypting traffic between Solr pods.
Enabling TLS for Solr is a straight-forward process once you have a [**PKCS12
keystore**]((https://en.wikipedia.org/wiki/PKCS_12)) containing an
[X.509](https://en.wikipedia.org/wiki/X.509) certificate and private key; as of
Java 8, PKCS12 is the default keystore format supported by the JVM.
-There are two basic use cases supported by the Solr operator. First, you can
use cert-manager to issue a certificate and store the resulting PKCS12 keystore
in a Kubernetes TLS secret.
+There are three basic use cases supported by the Solr operator. First, you can
use cert-manager to issue a certificate and store the resulting PKCS12 keystore
in a Kubernetes TLS secret.
Alternatively, you can create the TLS secret manually from a certificate
obtained by some other means. In both cases, you simply point your SolrCloud
CRD to the resulting TLS secret and corresponding keystore password secret.
+Lastly, as of **v0.4.0**, you can supply the path to a directory containing
TLS files that are mounted by some external agent or CSI driver.
### Use cert-manager to issue the certificate
[cert-manager](https://cert-manager.io/docs/) is a popular Kubernetes
controller for managing TLS certificates, including renewing certificates prior
to expiration.
One of the primary benefits of cert-manager is it supports pluggable
certificate `Issuer` implementations, including a self-signed Issuer for local
development and an [ACME compliant](https://tools.ietf.org/html/rfc8555) Issuer
for working with services like [Let’s Encrypt](https://letsencrypt.org/).
-If you already have a TLS certificate you want to use for Solr, then you don't
need cert-manager and can skip down to [I already have a TLS
Certificate](#-Already-Have-a-TLS-Certificate) later in this section.
+If you already have a TLS certificate you want to use for Solr, then you don't
need cert-manager and can skip down to [I already have a TLS
Certificate](#i-already-have-a-tls-certificate) later in this section.
If you do not have a TLS certificate, then we recommend installing
**cert-manager** as it makes working with TLS in Kubernetes much easier.
#### Install cert-manager
@@ -313,7 +341,7 @@ issuers.cert-manager.io
orders.acme.cert-manager.io
```
-If not intalled, use Helm to install it into the `cert-manager` namespace:
+If not installed, use Helm to install it into the `cert-manager` namespace:
```bash
if ! helm repo list | grep -q "https://charts.jetstack.io";; then
helm repo add jetstack https://charts.jetstack.io
@@ -492,7 +520,57 @@ spec:
```
_Tip: if your truststore is not in PKCS12 format, use `openssl` to convert
it._
-### Ingress
+### Mounted TLS Directory
+_Since v0.4.0_
+
+The options discussed to this point require that all Solr pods share the same
certificate and truststore. An emerging pattern in the Kubernetes ecosystem is
to issue a unique certificate for each pod.
+Typically this operation is performed by an external agent, such as a
cert-manager extension, that uses mutating webhooks to mount a unique
certificate and supporting files on each pod dynamically.
+How the pod-specific certificates get issued is beyond the scope of the Solr
operator. Under this scheme, you can use `spec.solrTLS.mountedTLSDir.path` to
specify the path where the TLS files are mounted on the main pod.
+The following example illustrates how to configure a keystore and truststore
in PKCS12 format using the `mountedTLSDir` option:
+```yaml
+spec:
+ ... other SolrCloud CRD settings ...
+
+ solrTLS:
+ clientAuth: Want
+ checkPeerName: true
+ verifyClientHostname: true
+ mountedTLSDir:
+ path: /pod-server-tls
+ keystoreFile: keystore.p12
+ keystorePasswordFile: keystore-password
+ truststoreFile: truststore.p12
+```
+
+When using the mounted TLS directory option, you need to ensure each Solr pod
gets restarted before the certificate expires. Solr does not support hot
reloading of the keystore or truststore.
+Consequently, we recommend using the `spec.updateStrategy.restartSchedule` to
restart pods before the certificate expires.
+Typically, with this scheme, a new certificate is issued whenever a pod is
restarted.
+
+### Client TLS
+_Since v0.4.0_
+
+Solr supports using separate client and server TLS certificates. Solr uses the
client certificate in mutual TLS (mTLS) scenarios to make requests to other
Solr pods.
+Use the `spec.solrClientTLS` configuration options to configure a separate
client certificate.
+As this is an advanced option, the supplied client certificate keystore and
truststore must already be in PKCS12 format.
+As with the server certificate loaded from `spec.solrTLS.pkcs12Secret`,
+you can have the operator restart Solr pods after the client TLS secret
updates by setting `spec.solrClientTLS.restartOnTLSSecretUpdate` to `true`.
+
+You may need to increase the timeout for the liveness / readiness probes when
using mTLS with a separate client certificate, such as:
+```yaml
+spec:
+ ... other SolrCloud CRD settings ...
+
+ customSolrKubeOptions:
+ podOptions:
+ livenessProbe:
+ timeoutSeconds: 10
+ readinessProbe:
+ timeoutSeconds: 10
+```
+
+You may also use the `spec.solrClientTLS.mountedTLSDir` option to load a pod
specific client certificate from a directory mounted by an external agent or
CSI driver.
+
+### Ingress with TLS protected Solr
The Solr operator may create an Ingress for exposing Solr pods externally.
When TLS is enabled, the operator adds the following annotation and TLS
settings to the Ingress manifest, such as:
```yaml
@@ -508,6 +586,10 @@ spec:
- secretName: my-selfsigned-cert-tls
```
+If using the mounted TLS Directory option with an Ingress, you will need to
inject the ingress with TLS information as well.
+The [Ingress TLS Termination section below](#enable-ingress-tls-termination)
shows how this can be done when using cert-manager.
+
+
### Certificate Renewal and Rolling Restarts
cert-manager automatically handles certificate renewal. From the docs:
@@ -600,7 +682,7 @@ which you can request TLS certificates from LetsEncrypt
assuming you own the `k8
Mutual TLS (mTLS) provides an additional layer of security by ensuring the
client applications sending requests to Solr are trusted.
To enable mTLS, simply set `spec.solrTLS.clientAuth` to either `Want` or
`Need`. When mTLS is enabled, the Solr operator needs to
supply a client certificate that is trusted by Solr; the operator makes API
calls to Solr to get cluster status.
-To configure the client certificate for the operator, see [Running the
Operator >
mTLS](../running-the-operator.md#Client-Auth-for-mTLS-enabled-Solr-clusters)
+To configure the client certificate for the operator, see [Running the
Operator >
mTLS](../running-the-operator.md#client-auth-for-mtls-enabled-solr-clusters)
When mTLS is enabled, the liveness and readiness probes are configured to
execute a local command on each Solr pod instead of the default HTTP Get
request.
Using a command is required so that we can use the correct TLS certificate
when making an HTTPs call to the probe endpoints.
@@ -617,6 +699,62 @@ curl "https://localhost:8983/solr/admin/info/system"; -v \
```
The `--cacert` option supplies the CA's certificate needed to trust the server
certificate provided by the Solr pods during TLS handshake.
+## Enable Ingress TLS Termination
+_Since v0.4.0_
+
+A common approach to securing traffic to your Solr cluster is to perform **TLS
termination** at the Ingress and either leave all traffic between Solr pods
un-encrypted or use private CAs for inter-pod communication.
+The operator supports this paradigm, to ensure all external traffic is
encrypted.
+
+```yaml
+kind: SolrCloud
+metadata:
+ name: search
+spec:
+ ... other SolrCloud CRD settings ...
+
+ solrAddressability:
+ external:
+ domainName: k8s.solr.cloud
+ method: Ingress
+ hideNodes: true
+ useExternalAddress: false
+ ingressTLSTerminationSecret: my-selfsigned-cert-tls
+```
+
+The only additional settings required here are:
+- Making sure that you are not using the external TLS address for Solr to
communicate internally via `useExternalAddress: false`.
+ This will be ignored, even if it is set to `true`.
+- Adding a TLS secret through `ingressTLSTerminationSecret`, this is passed to
the Kubernetes Ingress to handle the TLS termination.
+ _This ensures that the only way to communicate with your Solr cluster
externally is through the TLS protected common-endpoint._
+
+To generate a TLS secret, follow the [instructions
above](#use-cert-manager-to-issue-the-certificate) and use the templated
Hostname: `<namespace>-<name>-solrcloud.<domain>`
+
+If you configure your SolrCloud correctly, cert-manager can auto-inject the
TLS secrets for you as well:
+
+```yaml
+kind: SolrCloud
+metadata:
+ name: search
+ namespace: explore
+spec:
+ ... other SolrCloud CRD settings ...
+ customSolrKubeOptions:
+ ingressOptions:
+ annotations:
+ kubernetes.io/ingress.class: "nginx"
+ cert-manager.io/issuer: "<issuer-name>"
+ cert-manager.io/common-name: explore-search-solrcloud.apple.com
+ solrAddressability:
+ external:
+ domainName: k8s.solr.cloud
+ method: Ingress
+ hideNodes: true
+ useExternalAddress: false
+ ingressTLSTerminationSecret: myingress-cert
+```
+
+For more information on the Ingress TLS Termination options for cert-manager,
[refer to the documentation](https://cert-manager.io/docs/usage/ingress/).
+
## Authentication and Authorization
_Since v0.3.0_
@@ -765,6 +903,12 @@ Take a moment to review these authorization rules so that
you're aware of the ro
"collection": null,
"path": "/admin/metrics"
},
+ {
+ "name": "k8s-zk",
+ "role":"k8s",
+ "collection": null,
+ "path":"/admin/zookeeper/status"
+ },
{
"name": "k8s-ping",
"role": "k8s",
@@ -772,10 +916,6 @@ Take a moment to review these authorization rules so that
you're aware of the ro
"path": "/admin/ping"
},
{
- "name": "all",
- "role": [ "admin", "users" ]
- },
- {
"name": "read",
"role": [ "admin", "users" ]
},
@@ -785,11 +925,15 @@ Take a moment to review these authorization rules so that
you're aware of the ro
},
{
"name": "security-read",
- "role": "admin"
+ "role": [ "admin" ]
},
{
"name": "security-edit",
- "role": "admin"
+ "role": [ "admin" ]
+ },
+ {
+ "name": "all",
+ "role": [ "admin" ]
}
]
}
@@ -837,6 +981,10 @@ The exporter also hits the `/admin/ping` endpoint for
every collection, which re
```
The `"collection":"*"` setting indicates this path applies to all collections,
which maps to endpoint `/collections/<COLL>/admin/ping` at runtime.
+The initial authorization config grants the `read` permission to the `users`
role, which allows `users` to send query requests but cannot add / update /
delete documents.
+For instance, the `solr` user is mapped to the `users` role, so the `solr`
user can send query requests only.
+In general, please verify the initial authorization rules for each role before
sharing user credentials.
+
### Option 2: User-provided Basic Auth Secret
Alternatively, if users want full control over their cluster's security
config, then they can provide a `kubernetes.io/basic-auth` secret containing
the credentials for the user they want the operator to make API requests as:
@@ -903,4 +1051,4 @@ spec:
customSolrKubeOptions:
podOptions:
terminationGracePeriodSeconds: 120
-```
\ No newline at end of file
+```
diff --git a/docs/solr-prometheus-exporter/README.md
b/docs/solr-prometheus-exporter/README.md
index f27e20c..cc93f59 100644
--- a/docs/solr-prometheus-exporter/README.md
+++ b/docs/solr-prometheus-exporter/README.md
@@ -76,6 +76,11 @@ spec:
**This only applies to the SolrJ client the exporter uses to make requests to
your TLS-enabled Solr pods and does not enable HTTPS for the exporter service.**
+#### Mounted TLS Directory
+_Since v0.4.0_
+
+You can use the `spec.solrReference.solrTLS.mountedTLSDir.path` to point to a
directory containing certificate files mounted by an external agent or CSI
driver.
+
### Prometheus Exporter with Basic Auth
_Since v0.3.0_
diff --git a/docs/upgrade-notes.md b/docs/upgrade-notes.md
index 4c0c8dd..86e5e43 100644
--- a/docs/upgrade-notes.md
+++ b/docs/upgrade-notes.md
@@ -2,6 +2,29 @@
Please carefully read the entries for all versions between the version you are
running and the version you want to upgrade to.
+## Version Compatibility Matrixes
+
+### Kubernetes Versions
+
+| Solr Operator Version | `1.15` | `1.16` - `1.21` | `1.22`+ |
+| :---: | :---: | :---: | :---: |
+| `v0.2.6` | :heavy_check_mark: | :heavy_check_mark: | :x: |
+| `v0.2.7` | :x: | :heavy_check_mark: | :x: |
+| `v0.2.8` | :x: | :heavy_check_mark: | :x: |
+| `v0.3.0` | :x: | :heavy_check_mark: | :x: |
+| `v0.4.0` | :x: | :heavy_check_mark: | :x: |
+
+### Solr Versions
+
+| Solr Operator Version | `6.6` | `7.7` | `8.0` - `8.5` | `8.6`+ |
+| :---: | :---: | :---: | :---: | :---: |
+| `v0.2.6` | :grey_question: | :heavy_check_mark: | :heavy_check_mark: | :x: |
+| `v0.2.7` | :grey_question: | :heavy_check_mark: | :heavy_check_mark: |
:heavy_check_mark: |
+| `v0.2.8` | :grey_question: | :heavy_check_mark: | :heavy_check_mark: |
:heavy_check_mark: |
+| `v0.3.0` | :grey_question: | :heavy_check_mark: | :heavy_check_mark: |
:heavy_check_mark: |
+| `v0.4.0` | :grey_question: | :heavy_check_mark: | :heavy_check_mark: |
:heavy_check_mark: |
+
+
## Upgrading from `v0.2.x` to `v0.3.x`
If you are upgrading from `v0.2.x` to `v0.3.x`, please follow the [Upgrading
to Apache guide](upgrading-to-apache.md).
This is a special upgrade that requires different instructions.
@@ -45,14 +68,35 @@ If you are using the Solr Helm chart to deploy the
Zookeeper operator, then you
```bash
# Just replace the Solr CRDs and all CRDs it might depend on (e.g.
ZookeeperCluster)
-kubectl replace -f
"http://solr.apache.org/operator/downloads/crds/v0.3.0/all-with-dependencies.yaml";
-helm upgrade solr-operator apache-solr/solr-operator --version 0.3.0
+kubectl replace -f
"http://solr.apache.org/operator/downloads/crds/v0.4.0/all-with-dependencies.yaml";
+helm upgrade solr-operator apache-solr/solr-operator --version 0.4.0
```
_Note that the Helm chart version does not contain a `v` prefix, which the
downloads version does. The Helm chart version is the only part of the Solr
Operator release that does not use the `v` prefix._
## Upgrade Warnings and Notes
+### v0.4.0
+- The required version of the [Zookeeper
Operator](https://github.com/pravega/zookeeper-operator) to use with this
version has been upgraded from `v0.2.9` to `v0.2.12`.
+ If you use the Solr Operator helm chart, then by default the new version of
the Zookeeper Operator will be installed as well.
+ Refer to the helm chart documentation if you want to manage the Zookeeper
Operator installation yourself.
+ Please refer to the [Zookeeper Operator release
notes](https://github.com/pravega/zookeeper-operator/releases) before upgrading.
+ Make sure to install the correct version of the Zookeeper Operator CRDS, as
[shown above](#upgrading-the-zookeeper-operator).
+
+- The deprecated Solr Operator Helm chart option `useZkOperator` has been
removed, use `zookeeper-operator.use` instead.
+ **Note**: The old option takes a _string_ `"true"`/`"false"`, while the new
option takes a _boolean_ `true`/`false`.
+
+- The default Solr version for `SolrCloud` and `SolrPrometheusExporter`
resources has been upgraded from `7.7.0` to `8.9`.
+ This will not effect any existing resources, as default versions are
hard-written to the resources immediately.
+ Only new resources created after the Solr Operator is upgraded to `v0.4.0`
will be affected.
+
+- In previous versions of the Solr Operator, the provided Zookeeper instances
could only use Persistent Storage.
+ Now ephemeral storage is enabled, and used by default if Solr is using
ephemeral storage.
+ The ZK storage type can be explicitly set via
`Spec.zookeeperRef.provided.ephemeral` or
`Spec.zookeeperRef.provided.persistence`,
+ however if neither is set, the Solr Operator will default to use the type of
storage (persistent or ephemeral) that Solr is using.
+ **This means that the default Zookeeper Storage type can change for users
using ephemeral storage for Solr.
+ If you require ephemeral Solr storage and persistent Zookeeper Storage, be
sure to explicitly set that starting in `v0.4.0`.**
+
### v0.3.0
- All deprecated CRD fields and Solr Operator options from `v0.2.*` have been
removed.
@@ -123,4 +167,4 @@ _Note that the Helm chart version does not contain a `v`
prefix, which the downl
- Uses `gomod` instead of `dep`
- `SolrCloud.spec.zookeeperRef.provided.zookeeper.persistentVolumeClaimSpec`
has been **DEPRECATED** in favor of the
`SolrCloud.zookeeperRef.provided.zookeeper.persistence` option.
This option is backwards compatible, but will be removed in a future version
(`v0.3.0`).
-- An upgrade to the ZKOperator version `0.2.4` is required.
\ No newline at end of file
+- An upgrade to the ZKOperator version `0.2.4` is required.
