Further fixing

m3db · Aug 28, 2020 · e74c381 · e74c381
1 parent 3e357ac
commit e74c381
Show file tree

Hide file tree

Showing 12 changed files with 302 additions and 341 deletions.
diff --git a/docs/content/_index.md b/docs/content/_index.md
@@ -1,7 +1,7 @@
 ---
 date: 2020-04-01T19:26:56-04:00
 weight: 1
-chapter: false
+chapter: true
 ---
 
 # M3

diff --git a/docs/content/coordinator/index.md → docs/content/coordinator/_index.md b/docs/content/coordinator/index.md → docs/content/coordinator/_index.md
diff --git a/docs/content/coordinator/api/remote.md b/docs/content/coordinator/api/remote.md
@@ -22,9 +22,7 @@ None.
 
 #### Optional
 
---8<--
-docs/common/headers_optional_read_write.md
---8<--
+{{% codeinclude file="/common/headers_optional_read_write.md" language="shell" %}}
 
 ### Data Params
 

diff --git a/docs/content/m3db/architecture/commitlogs.md b/docs/content/m3db/architecture/commitlogs.md
@@ -8,8 +8,8 @@ M3DB has a commit log that is equivalent to the commit log or write-ahead-log in
 
 There are two integrity levels available for commit logs:
 
-- **Synchronous:** write operations must wait until it has finished writing an entry in the commit log to complete.
-- **Behind:** write operations must finish enqueueing an entry to the commit log write queue to complete.
+-   **Synchronous:** write operations must wait until it has finished writing an entry in the commit log to complete.
+-   **Behind:** write operations must finish enqueueing an entry to the commit log write queue to complete.
 
 Depending on the data loss requirements users can choose either integrity level.
 
@@ -23,7 +23,7 @@ Commit logs for a given time window are kept in a single file. An info structure
 
 The structures can be conceptually described as:
 
-```
+```golang
 CommitLogInfo {
   start int64
   duration int64
@@ -55,4 +55,4 @@ In addition, since the snapshot files are already compressed, bootstrapping from
 
 ### Cleanup
 
-Commit log files are automatically deleted once all the data they contain has been flushed to disk as immutable compressed filesets *or* all the data they contain has been captured by a compressed snapshot file. Similarly, snapshot files are deleted once all the data they contain has been flushed to disk as filesets.
+Commit log files are automatically deleted once all the data they contain has been flushed to disk as immutable compressed filesets _or_ all the data they contain has been captured by a compressed snapshot file. Similarly, snapshot files are deleted once all the data they contain has been flushed to disk as filesets.
diff --git a/docs/content/m3db/architecture/consistencylevels.md b/docs/content/m3db/architecture/consistencylevels.md
@@ -4,35 +4,23 @@ M3DB provides variable consistency levels for read and write operations, as well
 
 ## Write consistency levels
 
-* **One:** Corresponds to a single node succeeding for an operation to succeed.
-
-* **Majority:** Corresponds to the majority of nodes succeeding for an operation to succeed.
-
-* **All:** Corresponds to all nodes succeeding for an operation to succeed.
+-   **One:** Corresponds to a single node succeeding for an operation to succeed.
+-   **Majority:** Corresponds to the majority of nodes succeeding for an operation to succeed.
+-   **All:** Corresponds to all nodes succeeding for an operation to succeed.
 
 ## Read consistency levels
 
-* **One**: Corresponds to reading from a single node to designate success.
-
-* **UnstrictMajority**: Corresponds to reading from the majority of nodes but relaxing the constraint when it cannot be met, falling back to returning success when reading from at least a single node after attempting reading from the majority of nodes.
-
-* **Majority**: Corresponds to reading from the majority of nodes to designate success.
-
-* **All:** Corresponds to reading from all of the nodes to designate success.
+-   **One**: Corresponds to reading from a single node to designate success.
+-   **UnstrictMajority**: Corresponds to reading from the majority of nodes but relaxing the constraint when it cannot be met, falling back to returning success when reading from at least a single node after attempting reading from the majority of nodes.
+-   **Majority**: Corresponds to reading from the majority of nodes to designate success.
+-   **All:** Corresponds to reading from all of the nodes to designate success.
 
 ## Connect consistency levels
 
 Connect consistency levels are used to determine when a client session is deemed as connected before operations can be attempted.
 
-* **Any:** Corresponds to connecting to any number of nodes for all shards, this strategy will attempt to connect to all, then the majority, then one and then fallback to none and as such will always succeed.
-
-* **None:** Corresponds to connecting to no nodes for all shards and as such will always succeed.
-
-* **One:** Corresponds to connecting to a single node for all shards.
-
-
-* **Majority:** Corresponds to connecting to the majority of nodes for all shards.
-
-
-* **All:** Corresponds to connecting to all of the nodes for all shards.
-
+-   **Any:** Corresponds to connecting to any number of nodes for all shards, this strategy will attempt to connect to all, then the majority, then one and then fallback to none and as such will always succeed.
+-   **None:** Corresponds to connecting to no nodes for all shards and as such will always succeed.
+-   **One:** Corresponds to connecting to a single node for all shards.
+-   **Majority:** Corresponds to connecting to the majority of nodes for all shards.
+-   **All:** Corresponds to connecting to all of the nodes for all shards.
diff --git a/docs/content/m3db/architecture/engine.md b/docs/content/m3db/architecture/engine.md
diff --git a/docs/content/m3db/architecture/index.md b/docs/content/m3db/architecture/index.md
@@ -8,8 +8,6 @@ M3DB is written entirely in Go and does not have any required dependencies. For
 
 Some of the high level goals for the project are defined as:
 
-* **Monitoring support:** M3DB was primarily developed for collecting a high volume of monitoring time series data, distributing the storage in a horizontally scalable manner and most efficiently leveraging the hardware.  As such time series that are not read frequently are not kept in memory.
-
-* **Highly configurable:** Provide a high level of configuration to support a wide set of use cases and runtime environments.
-
-* **Variable durability:** Providing variable durability guarantees for the write and read side of storing time series data enables a wider variety of applications to use M3DB. This is why replication is primarily synchronous and is provided with configurable consistency levels, to enable consistent writes and reads. It must be possible to use M3DB with strong guarantees that data was replicated to a quorum of nodes and that the data was durable if desired.
+-   **Monitoring support:** M3DB was primarily developed for collecting a high volume of monitoring time series data, distributing the storage in a horizontally scalable manner and most efficiently leveraging the hardware.  As such time series that are not read frequently are not kept in memory.
+-   **Highly configurable:** Provide a high level of configuration to support a wide set of use cases and runtime environments.
+-   **Variable durability:** Providing variable durability guarantees for the write and read side of storing time series data enables a wider variety of applications to use M3DB. This is why replication is primarily synchronous and is provided with configurable consistency levels, to enable consistent writes and reads. It must be possible to use M3DB with strong guarantees that data was replicated to a quorum of nodes and that the data was durable if desired.