Add since versions to docs for features (#232)

Co-authored-by: Houston Putman <[email protected]>

Author: madrob

docs/solr-cloud/managed-updates.md

@@ -1,4 +1,5 @@
 # Managed SolrCloud Rolling Updates
+_Since v0.2.7_
 
 Solr Clouds are complex distributed systems, and thus require a more delicate and informed approach to rolling updates.
 

docs/solr-cloud/solr-cloud-crd.md

@@ -15,7 +15,9 @@ If neither is provided, ephemeral storage will be used by default.
 These options can be found in `SolrCloud.spec.dataStorage`
 
 - **`persistent`**
-  - **`reclaimPolicy`** - Either `Retain`, the default, or `Delete`.
+  - **`reclaimPolicy`** -
+    _Since v0.2.7_ -
+    Either `Retain`, the default, or `Delete`.
     This describes the lifecycle of PVCs that are deleted after the SolrCloud is deleted, or the SolrCloud is scaled down and the pods that the PVCs map to no longer exist.
     `Retain` is used by default, as that is the default Kubernetes policy, to leave PVCs in case pods, or StatefulSets are deleted accidentally.
 
@@ -37,6 +39,7 @@ These options can be found in `SolrCloud.spec.dataStorage`
   Only use this option when you require restoring the same backup to multiple SolrClouds.
 
 ## Update Strategy
+_Since v0.2.7_
 
 The SolrCloud CRD provides users the ability to define how Pod updates should be managed, through `SolrCloud.Spec.updateStrategy`.
 This provides the following options:
@@ -59,6 +62,7 @@ Under `SolrCloud.Spec.updateStrategy`:
   - **`maxShardReplicasUnavailable`** - The `maxShardReplicasUnavailable` is calculated independently for each shard, as the percentage of the number of replicas for that shard.
 
 ## Addressability
+_Since v0.2.6_
 
 The SolrCloud CRD provides users the ability to define how it is addressed, through the following options:
 
@@ -112,6 +116,7 @@ Under `spec.zookeeperRef`:
   - **`chroot`** - The chroot to use for the cluster
 
 #### ACLs
+_Since v0.2.7_
 
 The Solr Operator allows for users to specify ZK ACL references in their Solr Cloud CRDs.
 The user must specify the name of a secret that resides in the same namespace as the cloud, that contains an ACL username value and an ACL password value.
@@ -138,6 +143,7 @@ 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.
 
 ## Override Built-in Solr Configuration Files
+_Since v0.2.7_
 
 The Solr operator deploys well-configured SolrCloud instances with minimal input required from human operators. 
 As such, the operator installs various configuration files automatically, including `solr.xml` for node-level settings and `log4j2.xml` for logging. 
@@ -222,6 +228,7 @@ If the custom `solr.xml` changes in the user-provided ConfigMap, then the operat
 To summarize, if you need to customize `solr.xml`, provide your own version in a ConfigMap and changes made to the XML in the ConfigMap are automatically applied to your Solr pods.
 
 ### Custom Log Configuration
+_Since v0.3.0_
 
 By default, the Solr Docker image configures Solr to load its log configuration from `/var/solr/log4j2.xml`. 
 If you need to fine-tune the log configuration, then you can provide a custom `log4j2.xml` in a ConfigMap using the same basic process as described in the previous section for customizing `solr.xml`. If supplied, the operator overrides the log config using the `LOG4J_PROPS` env var.
@@ -254,6 +261,7 @@ 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.
 However, depending on how you expose Solr on your network, you may also want to encrypt traffic between Solr pods.
@@ -547,6 +555,7 @@ The example settings above will result in your Solr pods getting names like: `<n
 which you can request TLS certificates from LetsEncrypt assuming you own the `k8s.solr.cloud` domain.
 
 ## Authentication and Authorization
+_Since v0.3.0_
 
 All well-configured Solr clusters should enforce users to authenticate, even for read-only operations. Even if you want
 to allow anonymous query requests from unknown users, you should make this explicit using Solr's rule-based authorization

docs/solr-prometheus-exporter/README.md

@@ -27,6 +27,7 @@ This name can be provided at: `SolrPrometheusExporter.spec.solrRef.cloud.name`
   This info can be provided at: `SolrPrometheusExporter.spec.solrRef.cloud.zkConnectionInfo`, with keys `internalConnectionString` and `chroot`
 
 #### ACLs
+_Since v0.2.7_
 
 The Prometheus Exporter can be set up to use ZK ACLs when connecting to Zookeeper.
 
@@ -53,11 +54,13 @@ In order to use this functionality, use the following spec field:
 
 
 ### Solr TLS
+_Since v0.3.0_
 
 If you're relying on a self-signed certificate (or any certificate that requires importing the CA into the Java trust store) for Solr pods, then the Prometheus Exporter will not be able to make requests for metrics.
 You'll need to duplicate your TLS config from your SolrCloud CRD definition to your Prometheus exporter CRD definition as shown in the example below:
 
-```
+```yaml
+spec:
   solrReference:
     cloud:
       name: "dev"
@@ -74,10 +77,11 @@ You'll need to duplicate your TLS config from your SolrCloud CRD definition to y
 **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.**
 
 ### Prometheus Exporter with Basic Auth
+_Since v0.3.0_
 
 If you enable basic auth for your SolrCloud cluster, then you need to point the Prometheus exporter at the basic auth secret containing the credentials for making API requests to `/admin/metrics` and `/admin/ping` for all collections.
 
-```
+```yaml
 spec:
   solrReference:
     basicAuthSecret: user-provided-secret
@@ -86,7 +90,7 @@ If you chose option #1 to have the operator bootstrap `security.json` for you, t
 `<CLOUD>-solrcloud-basic-auth`. If you chose option #2, then pass the same name that you used for your SolrCloud CRD instance.
 
 This user account will need access to the following endpoints in Solr:
-```
+```json
       {
         "name": "k8s-metrics",
         "role": "k8s",
@@ -112,7 +116,7 @@ The Prometheus Stack provides all the services you need for monitoring Kubernete
 ### Install Prometheus Stack
 
 Begin by installing the Prometheus Stack in the `monitoring` namespace with Helm release name `mon`:
-```
+```bash
 MONITOR_NS=monitoring
 PROM_OPER_REL=mon
 
@@ -134,15 +138,15 @@ helm upgrade --install ${PROM_OPER_REL} prometheus-community/kube-prometheus-sta
 _Refer to the Prometheus stack documentation for detailed instructions._
 
 Verify you have Prometheus / Grafana pods running in the `monitoring` namespace:
-```
+```bash
 kubectl get pods -n monitoring
 ```
 
 ### Deploy Prometheus Exporter for Solr Metrics
 
 Next, deploy a Solr Prometheus exporter for the SolrCloud you want to capture metrics from in the namespace where you're running SolrCloud, not in the `monitoring` namespace. 
 For instance, the following example creates a Prometheus exporter named `dev-prom-exporter` for a SolrCloud named `dev` deployed in the `dev` namespace:
-```
+```yaml
 apiVersion: solr.apache.org/v1beta1
 kind: SolrPrometheusExporter
 metadata:
@@ -161,7 +165,7 @@ spec:
 ```
 
 Look at the logs for your exporter pod to ensure it is running properly (notice we're using a label filter vs. addressing the pod by name):
-```
+```bash
 kubectl logs -l solr-prometheus-exporter=dev-prom-exporter
 ```
 You should see some log messages that look similar to:
@@ -171,12 +175,14 @@ INFO  - <timestamp>; org.apache.solr.prometheus.collector.SchedulerMetricsCollec
 ```
 
 You can also see the metrics that are exported by the pod by opening a port-forward to the exporter pod and hitting port 8080 with cURL:
-```
+```bash
 kubectl port-forward $(kubectl get pod -l solr-prometheus-exporter=dev-prom-exporter --no-headers -o custom-columns=":metadata.name") 8080
 
 curl http://localhost:8080/metrics
 ```
+
 #### Customize Prometheus Exporter Config
+_Since v0.3.0_
 
 Each Solr pod exposes metrics as JSON from the `/solr/admin/metrics` endpoint. To see this in action, open a port-forward to a Solr pod and send a request to `http://localhost:8983/solr/admin/metrics`.
 
@@ -187,13 +193,13 @@ By default, the Solr operator configures the exporter to use the config from `/o
 If you need to customize the metrics exposed to Prometheus, you'll need to provide a custom config XML via a ConfigMap and then configure the exporter CRD to point to it.
 
 For instance, let's imagine you need to expose a new metric to Prometheus. Start by pulling the default config from the exporter pod using:
-```
+```bash
 EXPORTER_POD_ID=$(kubectl get pod -l solr-prometheus-exporter=dev-prom-exporter --no-headers -o custom-columns=":metadata.name"`)
 
 kubectl cp $EXPORTER_POD_ID:/opt/solr/contrib/prometheus-exporter/conf/solr-exporter-config.xml ./solr-exporter-config.xml
 ```
 Create a ConfigMap with your customized XML config under the `solr-prometheus-exporter.xml` key.
-```
+```yaml
 apiVersion: v1
 data:
   solr-prometheus-exporter.xml: |
@@ -208,7 +214,7 @@ metadata:
 _Note: Using `kubectl create configmap --from-file` scrambles the XML formatting, so we recommend defining the configmap YAML as shown above to keep the XML formatted properly._
 
 Point to the custom ConfigMap in your Prometheus exporter definition using:
-```
+```yaml
 spec:
   customKubeOptions:
     configMapOptions:
@@ -224,24 +230,24 @@ The Solr operator creates a K8s `ClusterIP` service for load-balancing across ex
 For our example `dev-prom-exporter`, the service name is: `dev-prom-exporter-solr-metrics`
 
 Take a quick look at the labels on the service as you'll need them to define a service monitor in the next step.
-```
+```bash
 kubectl get svc dev-prom-exporter-solr-metrics --show-labels
 ```
 
 Also notice the ports that are exposed for this service:
-```
+```bash
 kubectl get svc dev-prom-exporter-solr-metrics --output jsonpath="{@.spec.ports}"
 ```
 You should see output similar to:
-```
+```json
 [{"name":"solr-metrics","port":80,"protocol":"TCP","targetPort":8080}]
 ```
 
 ### Create a Service Monitor
 The Prometheus operator (deployed with the Prometheus stack) uses service monitors to find which services to scrape metrics from. Thus, we need to define a service monitor for our exporter service `dev-prom-exporter-solr-metrics`.
 If you're not using the Prometheus operator, then you do not need a service monitor as Prometheus will scrape metrics using the `prometheus.io/*` pod annotations on the exporter service; see [Prometheus Configuration](https://prometheus.io/docs/prometheus/latest/configuration/configuration/). 
 
-```
+```yaml
 apiVersion: monitoring.coreos.com/v1
 kind: ServiceMonitor
 metadata:
@@ -267,7 +273,7 @@ There are a few important aspects of this service monitor definition:
 * The `endpoints` section identifies the port to scrape metrics from and the scrape interval; recall our service exposes the port as `solr-metrics`  
 
 Save the service monitor YAML to a file, such as `dev-prom-service-monitor.yaml` and apply to the `monitoring` namespace:
-```
+```bash
 kubectl apply -f dev-prom-service-monitor.yaml -n monitoring
 ```
 
@@ -276,7 +282,7 @@ Prometheus is now configured to scrape metrics from the exporter service.
 ### Load Solr Dashboard in Grafana
 
 You can expose Grafana via a LoadBalancer (or Ingress) but for now, we'll just open a port-forward to port 3000 to access Grafana:
-```
+```bash
 GRAFANA_POD_ID=$(kubectl get pod -l app.kubernetes.io/name=grafana --no-headers -o custom-columns=":metadata.name" -n monitoring)
 kubectl port-forward -n monitoring $GRAFANA_POD_ID 3000
 ```