[glossary] Remove acronyms [M-N]

- Remove acronym-only entries starting with [M-N].
- Consolodate duplicate entries.
- Resolve glossary references.

Change-Id: I43626ea547b4520e1da51411d982f16005827d68
Implements: blueprint improve-glossary-usage

doc/common/glossary.rst

@@ -2460,11 +2460,10 @@ N
       connectivity. In Networking terminology, a network is always a layer-2
       network.
 
-   NAT
+   Network Address Translation (NAT)
 
-      Network Address Translation; Process of modifying IP address
-      information while in transit. Supported by Compute and
-      Networking.
+      Process of modifying IP address information while in transit.
+      Supported by Compute and Networking.
 
    network controller
 
@@ -2503,6 +2502,11 @@ N
       Represents a virtual, isolated OSI layer-2 subnet in
       Networking.
 
+   Network Time Protocol (NTP)
+
+      Method of keeping a clock for a host or node correct via
+      communication with a trusted, accurate time source.
+
    Newton
 
       The code name for the fourteenth release of OpenStack. The
@@ -2511,12 +2515,6 @@ N
       1013 E. Ninth St., Austin, TX. which is listed on the
       National Register of Historic Places.
 
-   NTP
-
-      Network Time Protocol; Method of keeping a clock for a host or
-      node correct via communication with a trusted, accurate time
-      source.
-
    network UUID
 
       Unique ID for a Networking network segment.

doc/install-guide/source/environment-networking.rst

@@ -41,21 +41,22 @@ Host networking
 
 All nodes require Internet access for administrative purposes such as package
 installation, security updates, :term:`DNS <Domain Name System (DNS)>`, and
-:term:`NTP`. In most cases, nodes should obtain internet access through the
-management network interface.
+:term:`NTP <Network Time Protocol (NTP)>`. In most cases, nodes should obtain
+internet access through the management network interface.
 To highlight the importance of network separation, the example architectures
 use `private address space <https://tools.ietf.org/html/rfc1918>`__ for the
 management network and assume that the physical network infrastructure
-provides Internet access via :term:`NAT` or other method. The example
-architectures use routable IP address space for the provider (external)
-network and assume that the physical network infrastructure provides direct
-Internet access.
+provides Internet access via :term:`NAT <Network Address Translation (NAT)>`
+or other method. The example architectures use routable IP address space for
+the provider (external) network and assume that the physical network
+infrastructure provides direct Internet access.
 
 In the provider networks architecture, all instances attach directly
 to the provider network. In the self-service (private) networks architecture,
 instances can attach to a self-service or provider network. Self-service
 networks can reside entirely within OpenStack or provide some level of external
-network access using :term:`NAT` through the provider network.
+network access using :term:`NAT <Network Address Translation (NAT)>` through
+the provider network.
 
 .. _figure-networklayout:
 
@@ -69,7 +70,7 @@ The example architectures assume use of the following networks:
   This network requires a gateway to provide Internet access to all
   nodes for administrative purposes such as package installation,
   security updates, :term:`DNS <Domain Name System (DNS)>`, and
-  :term:`NTP`.
+  :term:`NTP <Network Time Protocol (NTP)>`.
 
 * Provider on 203.0.113.0/24 with gateway 203.0.113.1
 

doc/install-guide/source/environment-ntp.rst

@@ -3,10 +3,10 @@
 Network Time Protocol (NTP)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-You should install Chrony, an implementation of :term:`NTP`, to properly
-synchronize services among nodes. We recommend that you configure the
-controller node to reference more accurate (lower stratum) servers and other
-nodes to reference the controller node.
+You should install Chrony, an implementation of :term:`NTP <Network Time
+Protocol (NTP)>`, to properly synchronize services among nodes. We recommend
+that you configure the controller node to reference more accurate (lower
+stratum) servers and other nodes to reference the controller node.
 
 .. toctree::
    :maxdepth: 1

doc/install-guide/source/overview.rst

@@ -139,7 +139,8 @@ Controller
 The controller node runs the Identity service, Image service, management
 portions of Compute, management portion of Networking, various Networking
 agents, and the dashboard. It also includes supporting services such as
-an SQL database, :term:`message queue`, and :term:`NTP`.
+an SQL database, :term:`message queue`, and :term:`NTP <Network Time Protocol
+(NTP)>`.
 
 Optionally, the controller node runs portions of Block Storage, Object
 Storage, Orchestration, and Telemetry services.
@@ -225,8 +226,8 @@ The self-service networks option augments the provider networks option
 with layer-3 (routing) services that enable
 :term:`self-service` networks using overlay segmentation methods such
 as :term:`VXLAN`. Essentially, it routes virtual networks to physical networks
-using :term:`NAT`. Additionally, this option provides the foundation
-for advanced services such as LBaaS and FWaaS.
+using :term:`NAT<Network Address Translation (NAT)>`. Additionally, this option
+provides the foundation for advanced services such as LBaaS and FWaaS.
 
 .. _figure-network2-services:
 

doc/networking-guide/source/intro-os-networking.rst

@@ -15,8 +15,8 @@ define network connectivity and addressing in the cloud. The Networking
 service enables operators to leverage different networking technologies
 to power their cloud networking. The Networking service also provides an
 API to configure and manage a variety of network services ranging from L3
-forwarding and :term:`NAT` to load balancing, perimeter firewalls, and
-virtual private networks.
+forwarding and :term:`NAT <Network Address Translation (NAT)>` to load
+balancing, perimeter firewalls, and virtual private networks.
 
 It includes the following components:
 

doc/ops-guide/source/arch-example-nova-network.rst

@@ -184,7 +184,7 @@ Why use multi-host networking?
 In a default OpenStack deployment, there is a single ``nova-network``
 service that runs within the cloud (usually on the cloud controller)
 that provides services such as
-:term:`network address translation <NAT>` (NAT), :term:`DHCP <Dynamic Host
+:term:`Network Address Translation (NAT)`, :term:`DHCP <Dynamic Host
 Configuration Protocol (DHCP)>`, and :term:`DNS <Domain Name System (DNS)>`
 to the guest instances. If the single node that runs the ``nova-network``
 service goes down, you cannot access your instances, and the instances
@@ -205,7 +205,7 @@ Detailed Description
 The reference architecture consists of multiple compute nodes, a cloud
 controller, an external NFS storage server for instance storage, and an
 OpenStack Block Storage server for volume storage.
-A network time service (:term:`Network Time Protocol <NTP>`, or NTP)
+A network time service (:term:`Network Time Protocol (NTP)`)
 synchronizes time on all the nodes. FlatDHCPManager in
 multi-host mode is used for the networking. A logical diagram for this
 example architecture shows which services are running on each node: