Add blank line for list (#1566)

The format of these files is wrong in the web. Signed-off-by: dongwenjuan <[email protected]>
thanos-io · Sep 25, 2019 · b788fb4 · b788fb4
1 parent 3fe208f
commit b788fb4
Show file tree

Hide file tree

Showing 2 changed files with 4 additions and 0 deletions.
diff --git a/docs/proposals/201809_gossip-removal.md b/docs/proposals/201809_gossip-removal.md
@@ -18,12 +18,14 @@ that allows changing `StoreAPI`s on-the-fly.
 
 [Gossip](https://en.wikipedia.org/wiki/Gossip_protocol) protocol (with the [membership](https://github.com/hashicorp/memberlist) implementation)
 was built into Thanos from the very beginning. The main advantages over other solution to connect components were:
+
 * Auto-join and auto-drop of components based on health checks.
 * Propagation of tiny metadata.
 
 After a couple of month of maintaining Thanos project and various discussions with different users, we realized that those advantages
 are not outstanding anymore and are not worth keeping, compared to the issues gossip causes. There are numerous reasons why we should
 deprecate gossip:
+
 * Gossip has been proven to be extremely confusing for the new users. Peer logic and really confusing `cluster.advertise-address` that
 was sometimes able to magically deduce private IP address (and sometimes not!) were leading to lots of questions and issues.
 Something that was made for quick ramp-up into Thanos ("just click the button and it auto-joins everything") created lots of confusion

diff --git a/docs/proposals/201901-read-write-operations-bucket.md b/docs/proposals/201901-read-write-operations-bucket.md
@@ -26,12 +26,14 @@ every X minutes instead of watch and react to changes immediately)
 ## Motivation
 
 Thanos performs similar operations as Prometheus do on TSDB blocks with the following differences:
+
 * It operates on Object Storage API instead of local filesystem.
 * Operations are done from multiple processes that lack coordination.
 
 Moving from lock-based logic to coordination free and from strongly consistent local filesystem to potentially eventually
 consistent remote simplified "filesystem" in form of Object Storage API, causes additional cases that we need to consider
 in Thanos system, like:
+
 * Thanos sidecar or compactor crashes during the process of uploading the block. It uploaded index, 2 chunk files and crashed. How to ensure readers (e.g compactor, store gateway) will handle this gracefully?
 * Thanos compactor uploads compacted block and deletes source blocks. After next sync iteration it does not see a new block (read after write eventual consistency). It sees gap, wrongly plans next compaction and causes non-resolvable overlap.
 * Thanos compactor uploads compacted block and deletes source blocks. Thanos Store Gateway syncs every 3m so it missed that fact. Next query that hits store gateway tries to fetch deleted source blocks and fails.