OpenNMS · Bonrob2 · Jul 5, 2023 · Jun 30, 2023 · Jul 4, 2023
diff --git a/docs/modules/deployment/pages/core/admin-password-reset.adoc b/docs/modules/deployment/pages/core/admin-password-reset.adoc
@@ -1,6 +1,7 @@
 
 [[reset-admin-password]]
 = Reset the Web UI Admin Password
+:description: Learn how to reset your OpenNMS Admin password on the command line.
 
 This section explains how to set the web UI admin password using the {page-component-title} installation script.
 

diff --git a/docs/modules/deployment/pages/core/getting-started.adoc b/docs/modules/deployment/pages/core/getting-started.adoc
@@ -1,6 +1,7 @@
 
 [[getting-started-core]]
 = Installation and Configuration
+:description: Install and configure OpenNMS instance including PostgreSQL set up on CentOS/RHEL 7-9, Debian/Ubuntu, and Docker.
 
 This section explains how to install and configure a new {page-component-title} instance.
 It describes how to do the following tasks:

diff --git a/docs/modules/deployment/pages/core/introduction.adoc b/docs/modules/deployment/pages/core/introduction.adoc
@@ -1,6 +1,7 @@
 
 [[basic-deployment]]
 = OpenNMS {page-component-title}
+:description: OpenNMS installation overview: PostgreSQL, REST endpoints, monitoring functions, provisioning, and web interface. OpenNMS architecture diagram.
 
 A basic {page-component-title} deployment installs and configures the core software, which includes PostgreSQL, REST endpoints, monitoring functions, provisioning, and the web interface.
 It also includes a set of xref:reference:daemons/introduction.adoc[daemons] for specific network management use cases.

diff --git a/docs/modules/deployment/pages/core/setup-message-broker.adoc b/docs/modules/deployment/pages/core/setup-message-broker.adoc
@@ -1,5 +1,6 @@
 [[setup-message-broker]]
 = Set up Message Broker
+:description: Learn how to set up and configure the following message brokers in OpenNMS: Kafka, ActiveMQ, Embedded ActiveMQ, and gRPC.
 
 Distributing {page-component-title} components like Minions and Sentinel require a messaging infrastructure.
 This section describes how to set up your {page-component-title} Core instance to use an existing messaging infrastructure based on ActiveMQ or Apache Kafka.

diff --git a/docs/modules/deployment/pages/core/system-requirements.adoc b/docs/modules/deployment/pages/core/system-requirements.adoc
@@ -1,5 +1,6 @@
 
 = Minimum System Requirements
+:description: OpenNMS system requirements, supported operating systems, version compatibility with Grafana, Cassandra, Elasticsearch, JDK, Kafka, PostgreSQL.
 
 Your system must meet the following minimum specifications to run {page-component-title}:
 

diff --git a/docs/modules/deployment/pages/minion/install.adoc b/docs/modules/deployment/pages/minion/install.adoc
@@ -1,6 +1,7 @@
 
 [[install-minion]]
 = Install Minion
+:description: How to install OpenNMS Minion on CentOS/RHEL 7-9, Debian/Ubuntu, Docker, and configure with message brokers: Kafka, ActiveMQ, Embedded ActiveMQ, gRPC.
 
 [[objectives]]
 == Objectives

diff --git a/docs/modules/deployment/pages/minion/installing-jdbc-driver.adoc b/docs/modules/deployment/pages/minion/installing-jdbc-driver.adoc
@@ -1,6 +1,7 @@
 
 [[install-jdbc-driver]]
 = Install JDBC Driver on Minion
+:description: How to install JDBC driver on an OpenNMS Minion with MySQL and Karaf.
 
 To detect, poll, or collect any JDBC service, you must install the corresponding JDBC driver.
 

diff --git a/docs/modules/deployment/pages/minion/introduction.adoc b/docs/modules/deployment/pages/minion/introduction.adoc
@@ -1,5 +1,6 @@
 
 = Minion
+:description: Learn about the OpenNMS Minion: benefits, how it works. Includes architecture diagram with three Minions.
 
 A Minion is an instance of the Karaf OSGi runtime that enables {page-component-title} to monitor devices and services in locations that it otherwise cannot reach.
 Minions communicate with these remote devices while {page-component-title} performs coordination and task delegation.

diff --git a/docs/modules/deployment/pages/minion/off-heap-storage.adoc b/docs/modules/deployment/pages/minion/off-heap-storage.adoc
@@ -1,7 +1,8 @@
 = Off-heap storage
+:description: Off-heap storage with the OpenNMS Minion.
 
 If a Minion loses connectivity with the broker (Kafka or ActiveMQ), then any received messages (syslog, flows, SNMP traps) are queued until connectivity is restored.
-This queue is limited by a fixed (and configurable) number of messages queued in the JVM heap and can optionally queue additional messages by persisting directly to the file system, avoiding heap memory use. 
+This queue is limited by a fixed (and configurable) number of messages queued in the JVM heap and can optionally queue additional messages by persisting directly to the file system, avoiding heap memory use.
 Once the queue is full, additional messages are dropped.
 
 The off-heap storage feature lets you extend the storage capacity by queuing messages outside of the JVM heap.

diff --git a/docs/modules/deployment/pages/minion/system-requirements.adoc b/docs/modules/deployment/pages/minion/system-requirements.adoc
@@ -1,6 +1,7 @@
 
 [[system-requirements-minion]]
 = Minimum System Requirements
+:description: Minimum requirements for OpenNMS Minion, including operating systems.
 
 The following hardware specs are the minimum required to run a Minion:
 

diff --git a/docs/modules/deployment/pages/opentracing/core.adoc b/docs/modules/deployment/pages/opentracing/core.adoc
@@ -1,3 +1,4 @@
+
 Enable tracing with Jaeger on Core instance by installing the `opennms-core-tracing-jaeger` feature and creating a configuration file with the Jaeger specific settings.
 
 NOTE: Configurations has to be made in the `etc` directory relative to the {page-component-title} Core home directory.

diff --git a/docs/modules/deployment/pages/opentracing/jaeger-tracing.adoc b/docs/modules/deployment/pages/opentracing/jaeger-tracing.adoc
@@ -1,13 +1,15 @@
-= Setting up Jaeger Tracing
+= Set up Jaeger Tracing
+
+:description: How to set up Jaeger tracing (OpenTracing) on an OpenNMS Core instance, Minion, or Sentinel.
 
 OpenTracing enables distributed tracing which makes it possible to monitor RPCs or transactions across process boundaries.
-You can leverage this functionality to help track and diagnose communication problems that may arise in distributed deployments of _{page-component-title}_ components; for example, Core instance, Minion, and/or Sentinel.
+You can leverage this functionality to help track and diagnose communication problems that may arise in distributed deployments of {page-component-title} components; for example, Core instance, Minion, and Sentinel.
 OpenTracing is supported on RPC calls between {page-component-title} Core instance for Sink API calls (including flows) between Minion and Sentinel.
 By default the tracing instrumentation {page-component-title} is disabled (a no-op tracer is used.)
 
 The project Jaeger is an open source, end-to-end distributed tracing software.
 It lets you monitor and troubleshoot transactions in distributed software components when {page-component-title} is deployed with Minion and Sentinel.
-_{page-component-title}_ components support link:https://www.jaegertracing.io/[Jaeger] which implements the OpenTracing API.
+{page-component-title} components support link:https://www.jaegertracing.io/[Jaeger] which implements the OpenTracing API.
 
 [{tabs}]
 ====

diff --git a/docs/modules/deployment/pages/sentinel/introduction.adoc b/docs/modules/deployment/pages/sentinel/introduction.adoc
@@ -1,4 +1,12 @@
 = Sentinel
+:description: Scale your network monitoring with OpenNMS Sentinel and support streaming telemetry with OpenNMS Newts on RHEL, CentOS, Debian, and Ubuntu.
+
+[[objectives]]
+== Objectives
+
+* Setting up a {page-component-title} Sentinel running on one of the following <<minion/system-requirements.adoc#operating-systems-Core, Operating Systems>>
+* Secure access with encrypted passwords to the Karaf shell
+* Sentinel can be configured with the Karaf Shell from th
 
 Sentinel provides scalability for data processing of flows and streaming telemetry received by one or more Minions.
 It also supports thresholding for streaming telemetry if you are using OpenNMS xref:deployment:time-series-storage/newts/introduction.adoc#ga-opennms-operation-newts[Newts].

diff --git a/docs/modules/deployment/pages/sentinel/runtime/install.adoc b/docs/modules/deployment/pages/sentinel/runtime/install.adoc
@@ -1,5 +1,6 @@
 [[install-sentinel]]
-= Installing Sentinel Runtime
+= Install Sentinel Runtime
+:description: Set up OpenNMS Sentinel (for scaling and streaming telemetry) on RHEL, CentOS, Debian, and Ubuntu.
 
 [[objectives]]
 == Objectives

diff --git a/docs/modules/deployment/pages/time-series-storage/newts/cassandra-jmx.adoc b/docs/modules/deployment/pages/time-series-storage/newts/cassandra-jmx.adoc
@@ -1,6 +1,7 @@
 
 [[cassandra-monitor]]
 = Cassandra Monitoring
+:description: Metrics OpenNMS collects from a Cassandra cluster: client connections, thread pools, JVM metrics, dropped messages, and more.
 
 This section describes some of the metrics that {page-component-title} collects from a Cassandra cluster.
 JMX must be enabled on the Cassandra nodes and made accessible from {page-component-title} in order to collect these metrics (see https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureJmxAuthentication.html[Enabling JMX Authentication and Authorization] in the Cassandra documentation).

diff --git a/docs/modules/deployment/pages/time-series-storage/newts/cassandra-newts-jmx.adoc b/docs/modules/deployment/pages/time-series-storage/newts/cassandra-newts-jmx.adoc
@@ -1,6 +1,7 @@
 
 [[newts-monitor]]
 = Newts Monitoring
+:description: Metrics OpenNMS collects to monitor Newts on a Cassandra node: memtables data, latency, pending operations, disk space usage, and more.
 
 This section describes the metrics that {page-component-title} collects to monitor the Newts keyspace from `org.apache.cassandra.metrics.Keyspace` on a Cassandra node.
 

diff --git a/docs/modules/deployment/pages/time-series-storage/newts/configuration.adoc b/docs/modules/deployment/pages/time-series-storage/newts/configuration.adoc
@@ -1,6 +1,7 @@
 
 [[newts-reference]]
 = Configuration Reference
+:description: Configuration properties for OpenNMS Newts, a time-series data store based on Apache Cassandra, for horizontal scaling.
 
 Use the following properties, found in `$\{OPENNMS_HOME}/etc/opennms.properties`, to configure Newts.
 

diff --git a/docs/modules/deployment/pages/time-series-storage/newts/introduction.adoc b/docs/modules/deployment/pages/time-series-storage/newts/introduction.adoc
@@ -1,6 +1,7 @@
 
 [[ga-opennms-operation-newts]]
 = Newts
+:description: Introduction to OpenNMS Newts, a time-series data store based on Apache Cassandra, for horizontal scaling.
 
 link:http://newts.io/[Newts] is a time series data schema for link:http://cassandra.apache.org/[Apache Cassandra].
 It enables link:https://en.wikipedia.org/wiki/Scalability#Horizontal[horizontal scaling] for your time series database and is an alternative to link:https://github.com/OpenNMS/jrobin[JRobin] and link:http://oss.oetiker.ch/rrdtool/[RRDtool].

diff --git a/...ules/deployment/pages/time-series-storage/newts/newts-repository-converter.adoc b/...ules/deployment/pages/time-series-storage/newts/newts-repository-converter.adoc
@@ -1,7 +1,8 @@
 
 = RRD/JRB to Newts Migration Utility
+:description: Learn how to migrate existing RRDtool or JRobin-based data to an OpenNMS Newts time series database schema.
 
-Use this utility to migrate existing RRDTool- or JRobin-based data to a Newts cluster.
+Use this utility to migrate existing RRDtool- or JRobin-based data to a Newts cluster.
 The migration process traverses the `$\{OPENNMS_HOME}/share/rrd` directory and its subdirectories, reads the data and properties files, and persists this data to Newts.
 
 == Migration

diff --git a/docs/modules/deployment/pages/time-series-storage/newts/newts.adoc b/docs/modules/deployment/pages/time-series-storage/newts/newts.adoc
@@ -1,6 +1,7 @@
 
 [[newts-configure]]
 = Configure {page-component-title} to Use Newts
+:description: How to set up OpenNMS Newts, a time-series data store based on Apache Cassandra, for horizontal scaling.
 
 This section describes how to configure your {page-component-title} instance to use Newts.
 

diff --git a/docs/modules/deployment/pages/time-series-storage/newts/resourcecli.adoc b/docs/modules/deployment/pages/time-series-storage/newts/resourcecli.adoc
@@ -1,5 +1,6 @@
 
 = Resource Management Tool
+:description: How to use the OpenNMS resource management tool to delete the collected data from a Horizon or Meridian instance: RRDtool, JRobin, and Newts.
 
 The resource management tool, resourcecli, simplifies the process of listing or manually deleting a {page-component-title} instance's collected data (resources).
 With RRDTool- or JRobin-based storage, this process is easy: you simply traverse the `$\{OPENNMS_HOME}/share/rrd` directory and its subdirectories.

diff --git a/docs/modules/deployment/pages/time-series-storage/timeseries/configuration.adoc b/docs/modules/deployment/pages/time-series-storage/timeseries/configuration.adoc
@@ -1,5 +1,6 @@
 
 = Enable Time Series Integration Layer
+:description: How to configure OpenNMS Horizon or Meridian to use the time series integration layer to support other time series databases.
 
 Set the following property in `$\{OPENNMS_HOME}/etc/opennms.properties.d/timeseries.properties` to configure {page-component-title} to use the Time Series Integration Layer:
 

diff --git a/docs/modules/deployment/pages/time-series-storage/timeseries/cortex.adoc b/docs/modules/deployment/pages/time-series-storage/timeseries/cortex.adoc
@@ -1,5 +1,6 @@
 
 = Cortex Time Series Plugin
+:description: Configuration and deployment for the OpenNMS Cortex Time Series plugin via Karaf shel or CFG file.
 
 The Cortex Time Series plugin enables {page-component-title} to persist time series performance and latency data to Cortex.
 The plugin uses the xref:time-series-storage/timeseries/ts-integration-layer.adoc[time series storage integration layer] to convert metrics to a Prometheus model and delegate writes and reads to https://cortexmetrics.io/[Cortex].

diff --git a/docs/modules/deployment/pages/time-series-storage/timeseries/hosted-tss.adoc b/docs/modules/deployment/pages/time-series-storage/timeseries/hosted-tss.adoc
@@ -1,6 +1,7 @@
 
 ifeval::["{page-component-title}" == "Meridian"]
 = OpenNMS Time Series DB
+:description: How to deploy the OpenNMS Time Series DB for a scalable time series database to store and persist performance metrics Meridian collects.
 
 The OpenNMS Time Series DB is a cloud-hosted service that provides a scalable time series database to store and persist performance metrics that {page-component-title} collects from monitored devices.
 

diff --git a/docs/modules/deployment/pages/time-series-storage/timeseries/rrdtool.adoc b/docs/modules/deployment/pages/time-series-storage/timeseries/rrdtool.adoc
@@ -1,9 +1,10 @@
 = RRDtool
+:description: Install and configure RRDtool for OpenNMS on RHEL, Centos, and Debian.
 
 Many open source applications use link:http://oss.oetiker.ch/rrdtool[RRDtool], which is the de-facto open standard for time series data.
 This section describes how to install RRDtool and how to configure your {page-component-title} Core instance to use it.
 
-WARNING: This guide does not cover data migration from JRobin to RRDTool.
+WARNING: This guide does not cover data migration from JRobin to RRDtool.
 
 Configurations must in the `etc` directory relative to the {page-component-title} Core home directory.
 Depending on your operating system, the home directory is `/usr/share/opennms` for Debian/Ubuntu or `/opt/opennms` for CentOS/RHEL.
@@ -37,12 +38,12 @@ rrd.binary=/usr/bin/rrdtool<5>
 
 <1> Set JNI RRD strategy class instead of JRobin.
 <2> Use the internal JRRD library.
-<3> Use the JRRD library to interface with RRDTool.
-<4> This is optional; use RRDTool to render graphs.
+<3> Use the JRRD library to interface with RRDtool.
+<4> This is optional; use RRDtool to render graphs.
 If unset, keep Backshift as default.
-<5> Path to the RRDTool binary file.
+<5> Path to the RRDtool binary file.
 
-TIP: If your RRDTool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
+TIP: If your RRDtool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
      `response-adhoc-graph.properties`, +
      `response-graph.properties`, +
      `snmp-adhoc-graph.properties`, +
@@ -60,7 +61,7 @@ sudo systemctl restart opennms
 find /opt/opennms/share/rrd -iname "*.rrd"
 ----
 
-NOTE: The first data collection creates RRDTool files with extension `.rrd`.
+NOTE: The first data collection creates RRDtool files with extension `.rrd`.
       JRobin files with extension `.jrb` are not updated.
       JRobin files are not deleted automatically.
       You must delete them manually.
@@ -93,12 +94,12 @@ rrd.binary=/usr/bin/rrdtool<5>
 
 <1> Set JNI RRD strategy class instead of JRobin.
 <2> Use the internal JRRD library.
-<3> Use the JRRD library to interface with RRDTool.
-<4> This is optional; use RRDTool to render graphs.
+<3> Use the JRRD library to interface with RRDtool.
+<4> This is optional; use RRDtool to render graphs.
 If unset, keep Backshift as default.
-<5> Path to the RRDTool binary file.
+<5> Path to the RRDtool binary file.
 
-TIP: If your RRDTool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
+TIP: If your RRDtool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
      `response-adhoc-graph.properties`, +
      `response-graph.properties`, +
      `snmp-adhoc-graph.properties`, +
@@ -116,7 +117,7 @@ sudo systemctl restart opennms
 find /opt/opennms/share/rrd -iname "*.rrd"
 ----
 
-NOTE: The first data collection creates RRDTool files with extension `.rrd`.
+NOTE: The first data collection creates RRDtool files with extension `.rrd`.
       JRobin files with extension `.jrb` are not updated.
       JRobin files are not deleted automatically.
       You must delete them manually.
@@ -148,12 +149,12 @@ rrd.binary=/usr/bin/rrdtool<5>
 
 <1> Set JNI RRD strategy class instead of JRobin.
 <2> Use the internal JRRD library.
-<3> Use the JRRD library to interface with RRDTool.
-<4> This is optional; use RRDTool to render graphs.
+<3> Use the JRRD library to interface with RRDtool.
+<4> This is optional; use RRDtool to render graphs.
 If unset, keep Backshift as default
-<5> Path to the RRDTool binary file.
+<5> Path to the RRDtool binary file.
 
-TIP: If your RRDTool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
+TIP: If your RRDtool binary is not in `/usr/bin/rrdtool`, adjust the path in the following files: +
      `response-adhoc-graph.properties`, +
      `response-graph.properties`, +
      `snmp-adhoc-graph.properties`, +
@@ -171,7 +172,7 @@ sudo systemctl restart opennms
 find /usr/share/opennms/share/rrd -iname "*.rrd"
 ----
 
-NOTE: The first data collection creates RRDTool files with extension `.rrd`.
+NOTE: The first data collection creates RRDtool files with extension `.rrd`.
       JRobin files with extension `.jrb` are not updated.
       JRobin files are not deleted automatically.
       You must delete them manually.

diff --git a/...odules/deployment/pages/time-series-storage/timeseries/time-series-storage.adoc b/...odules/deployment/pages/time-series-storage/timeseries/time-series-storage.adoc
@@ -1,6 +1,7 @@
 
 [[time-series-storage]]
 = Time Series Database
+:description: Overview of OpenNMS time series database options: JRobin, RRDtool, Newts, ONMS Time Series DB (Meridian only). Plugins and parallel series writes.
 
 {page-component-title} stores performance data in a time series database (JRobin by default).
 For different scenarios you may want to use a different time series database.
@@ -13,13 +14,13 @@ The following implementations are installed by default:
 | Time Series Database  | Description
 
 | JRobin
-| JRobin is a clone of RRDTool written in Java and is the default time series database when you install {page-component-title}.
-It does not fully cover the latest RRDTool feature set.
+| JRobin is a clone of RRDtool written in Java and is the default time series database when you install {page-component-title}.
+It does not fully cover the latest RRDtool feature set.
 Data is stored on the local file system of the {page-component-title} node.
 Depending on I/O capabilities, it works well for small- to medium-size installations.
 
-| RRDTool
-| RRDTool is actively maintained and the de-facto standard for time series data.
+| RRDtool
+| RRDtool is actively maintained and the de-facto standard for time series data.
 Data is stored on the local file system of the {page-component-title} node.
 Depending on I/O capabilities it works well for small- to medium-size installations.
 
@@ -39,7 +40,7 @@ For more information, see xref:time-series-storage/timeseries/hosted-tss.adoc[].
 endif::[]
 |===
 
-This chapter describes how to configure {page-component-title} to use RRDTool, Newts, and the OpenNMS Time Series DB.
+This chapter describes how to configure {page-component-title} to use RRDtool, Newts, and the OpenNMS Time Series DB.
 
 == Time series database plugins
 

diff --git a/...dules/deployment/pages/time-series-storage/timeseries/ts-integration-layer.adoc b/...dules/deployment/pages/time-series-storage/timeseries/ts-integration-layer.adoc
@@ -1,6 +1,7 @@
 
 [[ts-integration-layer]]
 = Time Series Integration Layer
+:description: Overview of OpenNMS Horizon or Meridian using the Time Series Integration Layer to support other time series databases (experimental): In Memory, InfluxDB, TimescaleDB, Cortex.
 
 This section describes how to configure {page-component-title} to use the Time Series Integration Layer.
 

diff --git a/docs/modules/deployment/pages/upgrade/backup/introduction.adoc b/docs/modules/deployment/pages/upgrade/backup/introduction.adoc
@@ -1,5 +1,6 @@
 [[backup]]
 = Back up OpenNMS {page-component-title}
+:description: How to backup OpenNMS Horizon or Meridian components.
 
 This section describes a basic backup process for a default OpenNMS {page-component-title} xref:deployment:core/getting-started.adoc#getting-started-core[installation].
 OpenNMS {page-component-title} binaries, logs, RRD archives, configurations, and the database are backed up during this process.

diff --git a/docs/modules/deployment/pages/upgrade/basic.adoc b/docs/modules/deployment/pages/upgrade/basic.adoc
@@ -1,6 +1,7 @@
 
 [[upgrade-basic]]
 = Basic Upgrade Steps
+:description: Basic steps to upgrade OpenNMS Horizon or Meridian, including PostgreSQL upgrade and configuration.
 
 This procedure describes how to do a basic {page-component-title} upgrade.
 You may need to complete additional steps to upgrade in a more complex setup (for example, if you run more than one {page-component-title} instance, have more complex database migration requirements, or depending on the age of current version).

diff --git a/docs/modules/deployment/pages/upgrade/diff.adoc b/docs/modules/deployment/pages/upgrade/diff.adoc
@@ -1,5 +1,6 @@
 [[run_diff]]
 = Identify Changed Configuration Files
+:description: How to identify changed configuration files during an OpenNMS Horizon or Meridian upgrade.
 
 During an upgrade, {page-component-title} overwrites configuration files, so any customization you may have done will be lost.
 You need to back up your customized configuration files so that you can merge them into your upgraded system.

diff --git a/docs/modules/deployment/pages/upgrade/git-diff.adoc b/docs/modules/deployment/pages/upgrade/git-diff.adoc
@@ -1,5 +1,6 @@
 [[git-diff]]
 = Manage Configuration Changes with Git
+:description: How to use Git to manage OpenNMS configuration file changes to assist with Horizon or Meridian upgrades.
 
 This content was originally written on the OpenNMS Discourse forum (see https://opennms.discourse.group/t/managing-configuration-changes-with-git/2327[Managing Configuration Changes with Git]).
 

diff --git a/docs/modules/deployment/pages/upgrade/git-upgrade.adoc b/docs/modules/deployment/pages/upgrade/git-upgrade.adoc
@@ -1,5 +1,6 @@
 [[git-upgrade]]
 = Upgrade {page-component-title} with Git
+:description: How to use Git to upgrade OpenNMS Horizon or Meridian.
 
 This content was originally written on the OpenNMS Discourse forum (see https://opennms.discourse.group/t/managing-configuration-changes-with-git/2327[Managing Configuration Changes with Git]).
 Follow the directions here to upgrade with Git if you xref:deployment:upgrade/git-diff.adoc#git-diff[use Git to manage configuration changes].