Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add blank line for list #1566

Merged
merged 1 commit into from
Sep 25, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/proposals/201809_gossip-removal.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 2 additions & 0 deletions docs/proposals/201901-read-write-operations-bucket.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down