[lucene-solr] branch branch_8x updated: Ref Guide: 8.10 upgrade notes + typo fixes

[ct...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

ctargett pushed a commit to branch branch_8x
in repository https://gitbox.apache.org/repos/asf/lucene-solr.git


The following commit(s) were added to refs/heads/branch_8x by this push:
     new dbd7011  Ref Guide: 8.10 upgrade notes + typo fixes
dbd7011 is described below

commit dbd70113d9f67f5020e767240fa2006ca2bff3f4
Author: Cassandra Targett <ct...@apache.org>
AuthorDate: Tue Sep 14 09:34:27 2021 -0500

    Ref Guide: 8.10 upgrade notes + typo fixes
---
 .../src/basic-authentication-plugin.adoc           |  2 +-
 solr/solr-ref-guide/src/metrics-reporting.adoc     |  8 +--
 solr/solr-ref-guide/src/solr-upgrade-notes.adoc    | 68 ++++++++++++++++++++++
 .../src/zookeeper-access-control.adoc              |  8 ++-
 4 files changed, 79 insertions(+), 7 deletions(-)

diff --git a/solr/solr-ref-guide/src/basic-authentication-plugin.adoc b/solr/solr-ref-guide/src/basic-authentication-plugin.adoc
index 7b399ce..05f77ea 100644
--- a/solr/solr-ref-guide/src/basic-authentication-plugin.adoc
+++ b/solr/solr-ref-guide/src/basic-authentication-plugin.adoc
@@ -67,7 +67,7 @@ If `blockUnknown` does not appear in the `security.json` file, it will default t
 
 [WARNING]
 ====
-If you set `blockUnknown` to `false`, then *any* request that is not explicitly protected by a permission will be accessible by anonymous users!
+If you set `blockUnknown` to `false`, then *any* request that is not explicitly protected by a permission will be accessible to anonymous users!
 Consequently, you should define a role binding for every <<rule-based-authorization-plugin.adoc#permissions,predefined>> permission you want to protect.
 You can assign the special `role: null` binding for requests that you want to allow anonymous users to access. To protect all endpoints except those with `role:null`,
 you can add a role binding for the `all` permission and place it in the last position in `security.json`.
diff --git a/solr/solr-ref-guide/src/metrics-reporting.adoc b/solr/solr-ref-guide/src/metrics-reporting.adoc
index e5d98ae..4a6848b 100644
--- a/solr/solr-ref-guide/src/metrics-reporting.adoc
+++ b/solr/solr-ref-guide/src/metrics-reporting.adoc
@@ -690,16 +690,16 @@ parts supported by the `key` selector. This parameter can be specified multiple
 any expression. The API guarantees that the output will consist only of unique metric names even if
 multiple expressions match the same metric name. Note: order of multiple `expr` parameters matters here - only the first value of the first matching expression will be recorded, subsequent values for the same metric name
 produced by matching other expressions will be skipped.
-
++
 Fully-qualified expression consists of at least two and at most three regex patterns separated by
 colons: a registry pattern, colon, a metric pattern, and then an optional colon and metric property pattern.
 Colons and other regex meta-characters in names and in regular expressions MUST be escaped using backslash (`\`) character.
-
++
 *NOTE: when this parameter is used, any other selection methods are ignored.*
-
++
 Examples:
 
-* `expr=solr\.core\..*:QUERY\..*\.requestTimes:max_ms`
+* `expr=solr\.core\..\*:QUERY\..*\.requestTimes:max_ms`
 * `expr=solr\.jvm:system\.properties:user\..*`
 
 `compact`:: When false, a more verbose format of the response will be returned. Instead of a response like this:
diff --git a/solr/solr-ref-guide/src/solr-upgrade-notes.adoc b/solr/solr-ref-guide/src/solr-upgrade-notes.adoc
index 38b50de..00910fb 100644
--- a/solr/solr-ref-guide/src/solr-upgrade-notes.adoc
+++ b/solr/solr-ref-guide/src/solr-upgrade-notes.adoc
@@ -34,6 +34,74 @@ Detailed steps for upgrading a Solr cluster are in the section <<upgrading-a-sol
 
 If you are upgrading from 7.x, see the section <<Upgrading from 7.x Releases>> below.
 
+=== Solr 8.10
+
+See the https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote810[8.10 Release Notes^]
+for an overview of the main new features of Solr 8.10.
+
+When upgrading to 8.10.x users should be aware of the following major changes from 8.9.
+
+*Schema Designer UI*
+
+A new screen has been added to the Admin UI that allows you to interactively design a Solr schema using your documents.
+
+The designer screen provides a safe environment for you to:
+
+* Upload or paste sample documents to identify fields.
+* Get a "first" guess at what Solr thinks the field types in the fields should be.
+* Edit fields, field types, dynamic fields, and supporting files.
+* See how a field's analysis will impact your text.
+* Test how schema changes will impact query-time behavior.
+* Save your changes to a configset to use with a new collection.
+
+See the section <<schema-designer.adoc#,Schema Designer>> for full details.
+
+*Backups in S3*
+
+Following the redesign of backups in Solr 8.8 that allowed storage of incremental backups in Google Cloud environments, Solr 8.10 provides support for storing backups in Amazon S3 buckets.
+
+See the section <<making-and-restoring-backups.adoc#s3backuprepository,S3BackupRepository>> for how to configure.
+
+*Security Admin UI*
+
+Solr's Admin UI also got a new screen to support management of users, roles, and permissions.
+
+The new UI works when authentication and/or authorization has been enabled with `bin/solr auth` or by manually installing a `security.json` file.
+Before this, it provides a warning that your Solr instance is unsecured.
+
+See the section <<security-ui.adoc#,Security UI>> for details.
+
+*Solr SQL Improvements*
+
+A number of improvements have been made in Solr's SQL functionality:
+
+* Support added for `LIKE`, `IS NOT NULL`, `IS NULL`, and wildcards (for simplistic `LIKE` functionality).
+* Two new aggregation functions, `COUNT(DISTINCT field)` and `APPROX_COUNT_DISTINCT(field)`, have been added.
+* Queries using an `ORDER BY` clause can support `OFFSET` and `FETCH` operations.
+* Multi-valued fields can now be returned.
+* User permissions have been simplified so access to query endpoints `/sql`, `/select`, and `/export` is sufficient for full access for all SQL queries.
+
+*shards.preference*
+
+A new option for the `shards.preference` parameter allows selection of nodes based on whether or not the replica is a leader.
+Now adding `shards.preference=replica.leader:false` will limit queries only to replicas which are not currently their shard's leader.
+
+See the section <<distributed-requests.adoc#shards-preference-parameter,shards.preference Parameter>> for details and examples.
+
+*Metrics & Prometheus Exporter*
+
+A new `expr` option in the Metrics API allows for more advanced filtering of metrics based on regular expressions.
+See the section <<metrics-reporting.adoc#metrics-api,Metrics API>> for examples.
+
+The Prometheus Exporter's default `solr-exporter.config` has been improved to use the new `expr` option in the Metrics API to get a smaller set of metrics.
+The default metrics exported still include most metrics, but the configuration will be easier to trim as needed.
+This should help provide performance improvements in busy clusters being monitored by Prometheus.
+
+*ZooKeeper Credentials*
+
+ZooKeeper credentials can now be stored in a file whose location is defined with a system property instead of being passed in plain-text.
+See <<zookeeper-access-control.adoc#out-of-the-box-credential-implementations,Out of the Box Credential Implementations>> for how to set this up.
+
 === Solr 8.9
 
 See the https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote89[8.9 Release Notes^]
diff --git a/solr/solr-ref-guide/src/zookeeper-access-control.adoc b/solr/solr-ref-guide/src/zookeeper-access-control.adoc
index 550a534..132bb88 100644
--- a/solr/solr-ref-guide/src/zookeeper-access-control.adoc
+++ b/solr/solr-ref-guide/src/zookeeper-access-control.adoc
@@ -161,9 +161,13 @@ REM  -DzkDigestReadonlyUsername=readonly-user -DzkDigestReadonlyPassword=CHANGEM
 
 == Changing ACL Schemes
 
-Over the lifetime of operating your Solr cluster, you may decide to move from an unsecured ZooKeeper to a secured instance. Changing the configured `zkACLProvider` in `solr.xml` will ensure that newly created nodes are secure, but will not protect the already existing data. To modify all existing ACLs, you can use the `updateacls` command with Solr's ZkCLI. First uncomment the `SOLR_ZK_CREDS_AND_ACLS` environment variable definition in `server/scripts/cloud-scripts/zkcli.sh` (or `zkcli.b [...]
+Over the lifetime of operating your Solr cluster, you may decide to move from an unsecured ZooKeeper to a secured instance.
+Changing the configured `zkACLProvider` in `solr.xml` will ensure that newly created nodes are secure, but will not protect the already existing data.
 
-Changing ACLs in ZK should only be done while your SolrCloud cluster is stopped. Attempting to do so while Solr is running may result in inconsistent state and some nodes becoming inaccessible.
+To modify all existing ACLs, you can use the `updateacls` command with Solr's ZkCLI.
+First uncomment the `SOLR_ZK_CREDS_AND_ACLS` environment variable definition in `server/scripts/cloud-scripts/zkcli.sh` (or `zkcli.bat` on Windows) and fill in the passwords for the admin-user and the readonly-user - see above - then run `server/scripts/cloud-scripts/zkcli.sh -cmd updateacls /zk-path`, or on Windows run `server\scripts\cloud-scripts\zkcli.bat cmd updateacls /zk-path`.
+
+Changing ACLs in ZooKeeper should only be done while your SolrCloud cluster is stopped. Attempting to do so while Solr is running may result in inconsistent state and some nodes becoming inaccessible.
 
 The VM properties `zkACLProvider` and `zkCredentialsProvider`, included in the `SOLR_ZK_CREDS_AND_ACLS` environment variable in `zkcli.sh/.bat`, control the conversion: