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

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: epugh <22395+epugh@users.noreply.github.com>

Author: epugh

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-clusters[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-clusters[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[]