SOLR-18179: Better highlight and expand upon our Cluster concepts in the Ref Guide

changelog/unreleased/SOLR-18179-move-cluster-concepts-section.yml

@@ -0,0 +1,7 @@
+title: Move cluster concepts into Getting Started in Ref Guide
+type: changed
+authors:
+  - name: Eric Pugh
+links:
+  - name: SOLR-18179
+    url: https://issues.apache.org/jira/browse/SOLR-18179

solr/solr-ref-guide/modules/configuration-guide/pages/config-api.adoc

@@ -19,7 +19,7 @@
 
 The Config API enables manipulating various aspects of your `solrconfig.xml` using REST-like API calls.
 
-This feature is enabled by default and works similarly in both SolrCloud, user-managed clusters, and single-node installations.
+This feature is enabled by default and works similarly in both SolrCloud and user-managed clusters installations.
 Many commonly edited properties (such as cache sizes and commit settings) and request handler definitions can be changed with this API.
 
 When using this API, `solrconfig.xml` is not changed.
@@ -847,7 +847,7 @@ In order to be able to `update` and `delete` of the same item in `configoverlay.
 When using SolrCloud, every core watches the ZooKeeper directory for the configset being used with that core.
 If there are multiple cores in the same node using the same configset, only one ZooKeeper watch is used.
 
-TIP:: In a user-managed cluster or single-node installation, there is no watch (because ZooKeeper is not running).
+TIP:: In a user-managed cluster or standalone installation, there is no watch (because ZooKeeper is not running).
 
 For instance, if the configset 'myconf' is used by a core, the node would watch `/configs/myconf`.
 Every write operation performed through the API would 'touch' the directory and all watchers are notified.

solr/solr-ref-guide/modules/configuration-guide/pages/config-sets.adoc

@@ -60,9 +60,9 @@ However, users can impose stricter or looser limits on their systems by providin
 - System Property: `-Dsolr.configset.forbidden.file.types`
 - Environment Variable: `SOLR_CONFIG_SET_FORBIDDEN_FILE_TYPES`
 
-== Configsets in User-Managed Clusters or Single-Node Installations
+== Configsets in User-Managed Clusters or Standalone Installations
 
-If you are using Solr in a user-managed cluster or a single-node installation, configsets are managed on the filesystem.
+If you are using Solr in a user-managed cluster or a standalone installation, configsets are managed on the filesystem.
 
 Each Solr core can have it's very own configset located beneath it in a `<instance_dir>/conf/` dir.
 Here, it is not named or shared and the word _configset_ isn't found.

solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc

@@ -27,11 +27,11 @@ When you first install Solr, your home directory is `server/solr`.
 However, some examples may change this location (such as, if you run `bin/solr start -e cloud`, your home directory will be `example/cloud`).
 
 The home directory contains important configuration information and is the place where Solr will store its index.
-The layout of the home directory will look a little different when you are running Solr in a user-managed cluster or single-node installation vs. when you are running a SolrCloud cluster.
+The layout of the home directory will look a little different when you are running Solr in a user-managed cluster or standalone installation vs. when you are running a SolrCloud cluster.
 
 The crucial parts of the Solr home directory are shown in these examples:
 
-.User-Managed Cluster or Single-Node
+.User-Managed Cluster or Standalone
 [source,plain]
 ----
 <solr-home-directory>/
@@ -96,8 +96,8 @@ The Files screen in the Admin UI lets you browse & view configuration files (suc
 .The Files Screen
 image::configuration-files/files-screen.png[Files screen,height=400]
 
-If you are using xref:deployment-guide:cluster-types.adoc#solrcloud-mode[SolrCloud], the files displayed are the configuration files for this collection stored in ZooKeeper.
-In user-managed clusters or single-node installations, all files in the `conf` directory are displayed.
+If you are using xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud], the files displayed are the configuration files for this collection stored in ZooKeeper.
+In user-managed clusters or standalone installations, all files in the `conf` directory are displayed.
 
 The configuration files shown may or may not be used by the collection as use of the file depends on how they are referenced in either `solrconfig.xml` or your schema.
 

solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc

@@ -18,9 +18,9 @@
 // specific language governing permissions and limitations
 // under the License.
 
-The Core Admin API is primarily used under the covers by the xref:collections-api.adoc[] when running a xref:deployment-guide:cluster-types.adoc#solrcloud-mode[SolrCloud] cluster.
+The Core Admin API is primarily used under the covers by the xref:collections-api.adoc[] when running a xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud] cluster.
 
-SolrCloud users should not typically use the CoreAdmin API directly, but the API may be useful for users of user-managed clusters or single-node installations for core maintenance operations.
+SolrCloud users should not typically use the CoreAdmin API directly, but the API may be useful for users of user-managed clusters or standalone installations for core maintenance operations.
 
 The CoreAdmin API is implemented by the CoreAdminHandler, which is a special purpose xref:requesthandlers-searchcomponents.adoc[request handler] that is used to manage Solr cores.
 Unlike other request handlers, the CoreAdminHandler is not attached to a single core.

solr/solr-ref-guide/modules/configuration-guide/pages/libs.adoc

@@ -34,7 +34,7 @@ There are several special places you can place Solr plugin `.jar` files, describ
 |Location |Visible To |Purpose |Additional Notes
 |`<solr_install>/lib/` | Everything (Node-level plugins, Core-level plugins, `bin/solr` tools) |Any plugins that administrators want to make available to all of Solrand its tooling, esp. when building a custom Solr package or Dockerfile. |N/A
 |`<solr_home/lib/` | Node-level plugins, Core-level plugins |Useful when plugins should be made available to all of Solr, but cannot be put in `<solr_install>/lib/` for whatever reason (e.g. Solr installed on read-only file system) | Directory not present by default and must be created by administrators. See xref:deployment-guide:taking-solr-to-production.adoc[].
-|`<core_instance>/lib/` |Core-level plugins (for a specific core) |User-managed clusters or single-node installations that want to make a plugin visible to a specific Solr core, but not others. |Directory is not created by default, and must be created by administrators adjacent to `<core_instance>/conf/`
+|`<core_instance>/lib/` |Core-level plugins (for a specific core) |User-managed clusters or standalone installations that want to make a plugin visible to a specific Solr core, but not others. |Directory is not created by default, and must be created by administrators adjacent to `<core_instance>/conf/`
 |`<solr_install>/server/solr-webapp/webapp/WEB-INF/lib/` |Everything (Node-level plugins, Core-level plugins, `bin/solr` tools) |Intended for Solr's own jars and dependencies |Should not be used for plugins, except in the case of a few rare plugin typs whose documentation explicitly calls out the need for placement here.
 |`<solr_install>/server/lib/ext` |Everything (Node-level plugins, Core-level plugins, `bin/solr` tools) |Intended to contain Jetty jars and other things needed by the Jetty servlet classpath. Not typically used for plugins |N/A
 |===

solr/solr-ref-guide/modules/configuration-guide/pages/request-parameters-api.adoc

@@ -24,7 +24,7 @@ It is really another endpoint of the xref:config-api.adoc[] instead of a separat
 It does not replace or modify any sections of `solrconfig.xml`, but instead provides another approach to handling parameters used in requests.
 It behaves in the same way as the Config API, by storing parameters in another file that will be used at runtime.
 In this case, the parameters are stored in a file named `params.json`.
-This file is kept in ZooKeeper when running SolrCloud or in the `conf` directory of a user-managed cluster or single-node installation.
+This file is kept in ZooKeeper when running SolrCloud or in the `conf` directory of a user-managed cluster or standalone installation.
 
 The settings stored in `params.json` are used at query time to override settings defined in `solrconfig.xml` in some cases as described below.
 

solr/solr-ref-guide/modules/configuration-guide/pages/resource-loading.adoc

@@ -31,7 +31,7 @@ xref:managed-resources.adoc[] can be manipulated via APIs and do not need an exp
 
 xref:config-sets.adoc[] are the directories containing `solrconfig.xml`, the schema, and resources referenced by them.
 In SolrCloud they are stored in ZooKeeper.
-In a user-managed cluster and a single-node installation they are stored on the file system.
+In a user-managed cluster or standalone installation they are stored on the file system.
 In any mode, resources may be shared or may be dedicated to a configSet.
 Prefer to put resources here.
 

solr/solr-ref-guide/modules/configuration-guide/pages/update-request-processors.adoc

@@ -132,7 +132,7 @@ Once the above has been specified in `solrconfig.xml`, we can be refer to them i
 
 == Update Processors in SolrCloud
 
-In a user-managed cluster or a single-node installation, each update is run through all the update processors in a chain exactly once.
+In a user-managed cluster or standalone installation, each update is run through all the update processors in a chain exactly once.
 In SolrCloud, however, the behavior of update request processors deserves special consideration.
 
 A critical SolrCloud functionality is the routing and distributing of requests.

solr/solr-ref-guide/modules/deployment-guide/deployment-nav.adoc

@@ -30,7 +30,6 @@
 *** xref:docker-faq.adoc[]
 
 * Scaling Solr
-** xref:cluster-types.adoc[]
 ** SolrCloud Clusters
 *** xref:solrcloud-shards-indexing.adoc[]
 *** xref:solrcloud-recoveries-and-write-tolerance.adoc[]

solr/solr-ref-guide/modules/deployment-guide/pages/authentication-and-authorization-plugins.adoc

@@ -25,7 +25,7 @@ This allows for verifying a user's identity and for restricting access to resour
 
 Solr includes some plugins out of the box, and additional plugins can be developed using the authentication, authorization and audit logging frameworks described below.
 
-All authentication, authorization and audit logging plugins can work with Solr whether it is running as a cluster or a single-node installation.
+All authentication, authorization and audit logging plugins can work with Solr whether it is running as a cluster or standalone installation.
 All related configuration, including users and permission rules, are stored in a file named `security.json`.
 When using SolrCloud, this file must be located at the chroot of the ZooKeeper structure.  If no chroot was given, then it must be at the root.
 When running Solr in standalone mode (without ZooKeeper), this file must be in the `$SOLR_HOME` directory. When manually running Solr from an extracted archive, this will most likely be `server/solr`. If the service installer script is used, its default location will be `/var/solr/data`, which can be changed with options given to the service installer.
@@ -110,9 +110,9 @@ Once `security.json` has been uploaded to ZooKeeper, you should use the appropri
 You can edit it manually, but you must take care to remove any version data so it will be properly updated across all ZooKeeper nodes.
 The version data is found at the end of the `security.json` file, and will appear as the letter "v" followed by a number, such as `{"v":138}`.
 
-=== In a User-Managed Cluster or Single-Node Installation
+=== In a User-Managed Cluster or Standalone Installation
 
-When running Solr in either a user-managed cluster or a single-node installation, you create the `security.json` file and put it in the `$SOLR_HOME` directory for your installation (this is the same place you have located `solr.xml` and is usually `server/solr`).
+When running Solr in either a user-managed cluster or standalone installation, you create the `security.json` file and put it in the `$SOLR_HOME` directory for your installation (this is the same place you have located `solr.xml` and is usually `server/solr`).
 
 With a user-managed cluster, you will need to place `security.json` on each node of the cluster.
 
@@ -145,7 +145,7 @@ Specify the authentication plugin in `/security.json` as in this example:
 
 All of the content in the `authentication` block of `security.json` will be passed as a map to the plugin during initialization.
 
-An authentication plugin can also be used with a single-node Solr instance by passing in `-DauthenticationPlugin=<plugin class name>` during startup.
+An authentication plugin can also be used with standalone Solr instance by passing in `-DauthenticationPlugin=<plugin class name>` during startup.
 
 Currently available authentication plugins are:
 

solr/solr-ref-guide/modules/deployment-guide/pages/backup-restore.adoc

@@ -21,7 +21,7 @@ If you are worried about data loss, and of course you _should_ be, you need a wa
 
 Solr provides two approaches to backing up and restoring Solr cores or collections, depending on how you are running Solr.
 If you run a SolrCloud cluster, you will use the Collections API.
-If you run a user-managed cluster or a single-node installation, you will use the replication handler.
+If you run a user-managed cluster or a standalone installation, you will use the replication handler.
 
 [NOTE]
 ====
@@ -49,7 +49,7 @@ More information is available in the section xref:collection-management.adoc#lis
 * `action=DELETEBACKUP`: This command allows deletion of backup files or whole backups.
 More information is available in the section xref:collection-management.adoc#deletebackup[Delete Backups].
 
-== User-Managed Clusters and Single-Node Installations
+== User-Managed Clusters and Standalone Installations
 
 Backups and restoration uses Solr's replication handler.
 Out of the box, Solr includes implicit support for replication so this API can be used.

solr/solr-ref-guide/modules/deployment-guide/pages/basic-authentication-plugin.adoc

@@ -61,7 +61,7 @@ There are several options defined in this example:
 <5> The parameter `"forwardCredentials":false` means we let Solr's PKI authentication handle distributed request instead of forwarding the Basic Auth header.
 
 Save your settings to a file called `security.json` locally.
-If you are using Solr in single-node installation, you should put this file in `$SOLR_HOME`.
+If you are using Solr in standalone installation, you should put this file in `$SOLR_HOME`.
 
 If `blockUnknown` is not defined in the `security.json` file, it will default to `true`.
 This has the effect of requiring authentication for HTTP access to Solr.

solr/solr-ref-guide/modules/deployment-guide/pages/cloud-screens.adoc

@@ -21,8 +21,8 @@ This screen provides status information about each collection & node in your clu
 .Only Visible When using SolrCloud
 [NOTE]
 ====
-The "Cloud" menu option is only available when Solr is running xref:cluster-types.adoc#solrcloud-mode[SolrCloud].
-User-managed clusters or single-node installations will not display this option.
+The "Cloud" menu option is only available when Solr is running xref:getting-started:cluster-types.adoc#solrcloud-mode[SolrCloud].
+User-managed clusters or standalone installations will not display this option.
 ====
 
 Click on the "Cloud" option in the left-hand navigation, and a small sub-menu appears with options called "Nodes", "Tree", "ZK Status" and "Graph".