DOCSP-15360, DOCSP-15407 foreport address build errors part1

Author: andf-mongodb

source/administration/monitoring.txt

@@ -572,7 +572,7 @@ become primary.
 Once a :binary:`~bin.mongod` has terminated, it may not be possible to cleanly
 restart it on the *same* machine.
 
-.. topic:: Symlinks
+.. note:: Symlinks
 
    If any of its monitored directories is a symlink to other volumes, the
    Storage Node Watchdog does not monitor the symlink target.

source/core/backups.txt

@@ -91,7 +91,7 @@ and the :opsmgr:`Ops Manager Manual </>`.
 Back Up by Copying Underlying Data Files
 ----------------------------------------
 
-.. topic:: Considerations for Encrypted Storage Engines using AES256-GCM 
+.. note:: Considerations for Encrypted Storage Engines using AES256-GCM 
 
    .. include:: /includes/fact-aes256-backups.rst
 

source/core/causal-consistency-read-write-concerns.txt

@@ -136,7 +136,7 @@ the following causal consistency guarantees:
 
 |checkmark| Read own writes  |checkmark| Monotonic reads  |checkmark| Monotonic writes  |checkmark| Writes follow reads
 
-.. topic:: Scenario 1 (Read Concern "majority" and Write Concern "majority")
+.. note:: Scenario 1 (Read Concern "majority" and Write Concern "majority")
 
    During the transient period with two primaries, because only ``P``\
    :sub:`new` can fulfill writes with :writeconcern:`{ w: "majority" }
@@ -193,7 +193,7 @@ the following causal consistency guarantees:
           reflects a state of the data after Read\ :sub:`1` (i.e. an
           earlier state reflects the data read by Read\ :sub:`1`).
 
-.. topic:: Scenario 2 (Read Concern "majority" and Write Concern "majority")
+.. note:: Scenario 2 (Read Concern "majority" and Write Concern "majority")
 
    Consider an alternative sequence where Read\ :sub:`1` with read
    concern :readconcern:`"majority"` routes to ``S``\ :sub:`1`:
@@ -273,7 +273,7 @@ provides the following causal consistency guarantees *if causal consistency impl
 
 |checkmark| Read own writes  |checkmark| Monotonic reads  |checkmark| Monotonic writes  |checkmark| Writes follow reads
 
-.. topic:: Scenario 3 (Read Concern "majority" and Write Concern ``{w: 1}``)
+.. note:: Scenario 3 (Read Concern "majority" and Write Concern ``{w: 1}``)
 
    During the transient period with two primaries, because both ``P``\
    :sub:`old` and ``P``\ :sub:`new` can fulfill writes with
@@ -375,7 +375,7 @@ provides the following causal consistency guarantees *if causal consistency impl
           earlier state reflects the data read by Read\
           :sub:`1`).
 
-.. topic:: Scenario 4 (Read Concern "majority" and Write Concern ``{w: 1}``)
+.. note:: Scenario 4 (Read Concern "majority" and Write Concern ``{w: 1}``)
 
    Consider an alternative sequence where Read\ :sub:`1` with
    read concern :readconcern:`"majority"` routes to ``S``\ :sub:`1`:
@@ -482,7 +482,7 @@ cannot guarantee causal consistency.
 This combination may satisfy all four causal consistency guarantees in
 some situations, but not necessarily in all situations.
 
-.. topic:: Scenario 5 (Read Concern "local" and Write Concern ``{w: 1}``)
+.. note:: Scenario 5 (Read Concern "local" and Write Concern ``{w: 1}``)
 
    During this transient period, because both ``P``\ :sub:`old` and
    ``P``\ :sub:`new` can fulfill writes with :writeconcern:`{ w: 1 } <\<number\>>` write concern, a
@@ -553,7 +553,7 @@ the following causal consistency guarantees:
 This combination may satisfy all four causal consistency guarantees in
 some situations, but not necessarily in all situations.
 
-.. topic:: Scenario 6 (Read Concern "local" and Write Concern "majority")
+.. note:: Scenario 6 (Read Concern "local" and Write Concern "majority")
 
    During this transient period, because only ``P``\ :sub:`new` can
    fulfill writes with  :writeconcern:`{ w: "majority" } <"majority">` write concern, a client

source/core/data-model-operations.txt

@@ -139,9 +139,9 @@ the following behaviors:
 
 - For each :term:`database`, a single namespace file (i.e.
   ``<database>.ns``) stores all meta-data for that database, and each
-  index and collection has its own entry in the namespace file. MongoDB
-  places :limit:`limits on the size of namespace files
-  <Size of Namespace File>`.
+  index and collection has its own entry in the namespace file. See
+  places :ref:`namespace length limits <limit-namespace-length>` for
+  specific limitations.
 
 .. _faq-developers-embed-documents:
 

source/core/index-multikey.txt

@@ -128,7 +128,6 @@ For an example, see :ref:`multikey-embedded-documents`.
 .. seealso::
 
    - :ref:`unique-separate-documents`
-
    - :ref:`index-unique-index`
 
 Sorting

source/core/index-single.txt

@@ -63,7 +63,7 @@ You can create indexes on fields within embedded documents, just as you
 can index top-level fields in documents. Indexes on embedded fields
 differ from :ref:`indexes on embedded documents <index-embedded-documents>`,
 which include the full content up to the maximum :limit:`index size
-<Index Key>` of the embedded document in the index. Instead, indexes on
+<Index Key Limit>` of the embedded document in the index. Instead, indexes on
 embedded fields allow you to use a "dot notation," to introspect into
 embedded documents.
 

source/core/replica-set-architecture-three-members.txt

@@ -86,5 +86,4 @@ set will elect the secondary to be primary.
 
 .. seealso::
 
-   :doc:`/tutorial/deploy-replica-set`.
-
+   :doc:`/tutorial/deploy-replica-set`

source/core/retryable-writes.txt

@@ -156,7 +156,7 @@ cannot be :writeconcern:`{w: 0} <\<number\>>`.
        any multi-document write operations, such as ``update`` which
        specifies ``true`` for the ``multi`` option.
 
-.. topic:: Updates to Shard Key Values
+.. note:: Updates to Shard Key Values
 
    Starting in MongoDB 4.2, you can update a document's shard key value
    (unless the shard key field is the immutable ``_id`` field) by

source/core/security-encryption-at-rest.txt

@@ -49,7 +49,7 @@ Enterprise for Linux also supports authenticated encryption
 ``AES256-GCM`` (or 256-bit Advanced Encryption Standard in
 Galois/Counter Mode). FIPS mode encryption is also available.
 
-.. topic:: AES256-GCM and Filesystem Backups
+.. note:: AES256-GCM and Filesystem Backups
 
    .. include:: /includes/fact-aes256-backups.rst
 

source/core/sharding-balancer-administration.txt

@@ -176,7 +176,7 @@ All chunk migrations use the following procedure:
 
    .. seealso::
 
-      :ref:`moveChunk-directory`.
+      :ref:`moveChunk-directory`
 
 The migration process ensures consistency and maximizes the availability of
 chunks during balancing.