Cleanup white noise in Markdown files (cortexproject#2447)

* Cleanup white noise in Markdown files Signed-off-by: Marco Pracucci <[email protected]> * Fixed white noise Signed-off-by: Marco Pracucci <[email protected]>
eeldaly · Apr 14, 2020 · ba32254 · ba32254
1 parent d6093ac
commit ba32254
Show file tree

Hide file tree

Showing 18 changed files with 130 additions and 112 deletions.
diff --git a/.circleci/config.yml b/.circleci/config.yml
@@ -85,6 +85,9 @@ jobs:
     - run:
         name: Check generated documentation is consistent.
         command: make BUILD_IN_CONTAINER=false check-doc
+    - run:
+        name: Check white noise.
+        command: make BUILD_IN_CONTAINER=false check-white-noise
 
   test:
     docker:

diff --git a/CHANGELOG.md b/CHANGELOG.md
diff --git a/Makefile b/Makefile
@@ -9,6 +9,10 @@ IMAGE_TAG ?= $(if $(CIRCLE_TAG),$(CIRCLE_TAG),$(shell ./tools/image-tag))
 GIT_REVISION := $(shell git rev-parse HEAD)
 UPTODATE := .uptodate
 
+# Support gsed on OSX (installed via brew), falling back to sed. On Linux
+# systems gsed won't be installed, so will use sed as expected.
+SED ?= $(shell which gsed 2>/dev/null || which sed)
+
 # Building Docker images is now automated. The convention is every directory
 # with a Dockerfile in it builds an image calls quay.io/cortexproject/<dirname>.
 # Dependencies (i.e. things that go in the image) still need to be explicitly
@@ -199,6 +203,13 @@ clean-doc:
 check-doc: doc
 	@git diff --exit-code -- ./docs/configuration/config-file-reference.md ./docs/operations/blocks-storage.md
 
+clean-white-noise:
+	@find . -path ./.pkg -prune -o -path ./vendor -prune -o -path ./website -prune -or -type f -name "*.md" -print | \
+	SED_BIN="$(SED)" xargs ./tools/cleanup-white-noise.sh
+
+check-white-noise: clean-white-noise
+	@git diff --exit-code --quiet -- '*.md' || (echo "Please remove trailing whitespaces running 'make clean-white-noise'" && false)
+
 web-serve:
 	cd website && hugo --config config.toml -v server
 

diff --git a/RELEASE.md b/RELEASE.md
@@ -23,7 +23,7 @@ The release shepherd is responsible for the entire release series of a minor rel
 * We aim to keep the master branch in a working state at all times. In principle, it should be possible to cut a release from master at any time. In practice, things might not work out as nicely. A few days before the pre-release is scheduled, the shepherd should check the state of master. Following their best judgement, the shepherd should try to expedite bug fixes that are still in progress but should make it into the release. On the other hand, the shepherd may hold back merging last-minute invasive and risky changes that are better suited for the next minor release.
 * On the date listed in the table above, the release shepherd cuts the first pre-release (using the suffix `-rc.0`) and creates a new branch called  `release-<major>.<minor>` starting at the commit tagged for the pre-release. In general, a pre-release is considered a release candidate (that's what `rc` stands for) and should therefore not contain any known bugs that are planned to be fixed in the final release.
 * With the pre-release, the release shepherd is responsible for coordinating or running the release candidate in Grafana or WeaveWorks production for 3 days.
-* If regressions or critical bugs are detected, they need to get fixed before cutting a new pre-release (called `-rc.1`, `-rc.2`, etc.). 
+* If regressions or critical bugs are detected, they need to get fixed before cutting a new pre-release (called `-rc.1`, `-rc.2`, etc.).
 
 See the next section for details on cutting an individual release.
 

diff --git a/VENDORED_CODE.md b/VENDORED_CODE.md
@@ -7,11 +7,11 @@ entire license text they are under.
 The following bits of vendored code are under the MPL-2.0 and can be found
 in the ./vendor/ directory:
 
-- https://github.com/hashicorp/go-cleanhttp and  
+- https://github.com/hashicorp/go-cleanhttp and
   https://github.com/hashicorp/consul
-- Pulled in by dependencies are  
-  https://github.com/hashicorp/golang-lru  
-  https://github.com/hashicorp/serf  
+- Pulled in by dependencies are
+  https://github.com/hashicorp/golang-lru
+  https://github.com/hashicorp/serf
   https://github.com/hashicorp/go-rootcerts
 
 [One file used in tests](COPYING.LGPL-3) is under LGPL-3, that's why we ship

diff --git a/docs/case-studies/gojek.md b/docs/case-studies/gojek.md
@@ -2,12 +2,12 @@
 title: "How Gojek Is Leveraging Cortex to Keep Up with Its Ever-Growing Scale"
 linkTitle: "Gojek"
 weight: 1
-slug: gojek 
+slug: gojek
 ---
 
 [Gojek](https://www.gojek.com/) launched in 2010 as a call center for booking motorcycle taxi rides in Indonesia. Today, the startup is a decacorn serving  millions of users across Southeast Asia with its mobile wallet, GoPay, and 20+ products on its super app. Want to order dinner? Book a massage? Buy movie tickets? You can do all of that with the Gojek app.
 
-The company’s mission is to solve everyday challenges with technology innovation. To achieve that across multiple markets the systems team at Gojek focused on building an infrastructure for speed, reliability, and scale. By 2019, the team realized it needed a new monitoring system that could keep up with Gojek’s ever-growing technology organization, which led them to [Cortex](https://github.com/cortexproject/cortex), the horizontally scalable [Prometheus](https://prometheus.io/) implementation. 
+The company’s mission is to solve everyday challenges with technology innovation. To achieve that across multiple markets the systems team at Gojek focused on building an infrastructure for speed, reliability, and scale. By 2019, the team realized it needed a new monitoring system that could keep up with Gojek’s ever-growing technology organization, which led them to [Cortex](https://github.com/cortexproject/cortex), the horizontally scalable [Prometheus](https://prometheus.io/) implementation.
 
 “We were using InfluxDB for metrics storage. Developers configured alerts by committing kapacitor scripts in git repos. To achieve high availability, we had a relay setup with two InfluxDBs. Since we could not horizontally scale Influx unless we paid for an enterprise license, we ended up having many InfluxDB clusters with relay setup,” says Product Engineer Ankit Goel.
 
@@ -29,7 +29,7 @@ Cortex met all of these requirements, and also had the following features that t
 
 Because it supports remote_write, Cortex enabled one of Gojek’s key needs: the ability to offer monitoring as a service. “With Thanos, we would have had to deploy a Thanos sidecar on every Prometheus that would have been deployed,” says Goel. “So essentially, there would be a substantial part of infrastructure on the client side that we would need to manage. We preferred Cortex because people could simply push their metrics to us, and we would have all the metrics in a single place.”
 
-The implementation started in January 2019. The team developed a few tools: a simple service for token-based authentication, and another for storing team information, such as notification channels and PagerDuty policies. Once all this was done, they leveraged [InfluxData Telegraf’s remote_write plugin](https://github.com/achilles42/telegraf/tree/prometheus-remote-write) to write to Cortex. This allowed them to have all the metrics being sent to InfluxDB to be sent to Cortex as well. “So moving from InfluxDB to tenants would not be that complicated. Because Cortex was multi-tenant, we could directly map each of our InfluxDB servers to our tenants,” says Goel. They’ve developed an internal helm chart to deploy and manage Cortex. After the customizations were completed in about two months, “we had our setup up and running, and we onboarded one team on Cortex,” he says. 
+The implementation started in January 2019. The team developed a few tools: a simple service for token-based authentication, and another for storing team information, such as notification channels and PagerDuty policies. Once all this was done, they leveraged [InfluxData Telegraf’s remote_write plugin](https://github.com/achilles42/telegraf/tree/prometheus-remote-write) to write to Cortex. This allowed them to have all the metrics being sent to InfluxDB to be sent to Cortex as well. “So moving from InfluxDB to tenants would not be that complicated. Because Cortex was multi-tenant, we could directly map each of our InfluxDB servers to our tenants,” says Goel. They’ve developed an internal helm chart to deploy and manage Cortex. After the customizations were completed in about two months, “we had our setup up and running, and we onboarded one team on Cortex,” he says.
 
 In the initial version, GitOps was the only interface for developers to apply alerts and create dashboards. The team built tools like [grafonnet-playground](https://github.com/lahsivjar/grafonnet-playground) to make it easy for developers to create dashboards. Developers are also allowed to create dashboards using the UI, since Grafana maintains version history for dashboards.
 

diff --git a/docs/configuration/arguments.md b/docs/configuration/arguments.md
@@ -303,7 +303,7 @@ It also talks to a KVStore and has it's own copies of the same flags used by the
    Deprecated. New ingesters always write "normalised" tokens to the ring. Normalised tokens consume less memory to encode and decode; as the ring is unmarshalled regularly, this significantly reduces memory usage of anything that watches the ring.
 
    Cortex 0.4.0 is the last version that can *write* denormalised tokens. Cortex 0.5.0 and above always write normalised tokens.
-   
+
    Cortex 0.6.0 is the last version that can *read* denormalised tokens. Starting with Cortex 0.7.0 only normalised tokens are supported, and ingesters writing denormalised tokens to the ring (running Cortex 0.4.0 or earlier with `-ingester.normalise-tokens=false`) are ignored by distributors. Such ingesters should either switch to using normalised tokens, or be upgraded to Cortex 0.5.0 or later.
 
 - `-ingester.chunk-encoding`
@@ -343,7 +343,7 @@ It also talks to a KVStore and has it's own copies of the same flags used by the
 
    Setting this to `true` enables writing to WAL during ingestion.
 
-- `-ingester.checkpoint-duration` 
+- `-ingester.checkpoint-duration`
    This is the interval at which checkpoints should be created.
 
 - `-ingester.recover-from-wal`

diff --git a/docs/configuration/schema-config-reference.md b/docs/configuration/schema-config-reference.md
@@ -5,7 +5,7 @@ weight: 4
 slug: schema-configuration
 ---
 
-Cortex uses a NoSQL Store to store its index and optionally an Object store to store its chunks. Cortex has overtime evolved its schema to be more optimal and better fit the use cases and query patterns that arose. 
+Cortex uses a NoSQL Store to store its index and optionally an Object store to store its chunks. Cortex has overtime evolved its schema to be more optimal and better fit the use cases and query patterns that arose.
 
 Currently there are 9 schemas that are used in production but we recommend running with `v9` schema when possible. You can move from one schema to another if a new schema fits your purpose better, but you still need to configure Cortex to make sure it can read the old data in the old schemas.
 
@@ -45,12 +45,12 @@ configs:
   - from: "2020-03-01" # Or typically a week before the Cortex cluster was created.
     schema: v9
     index:
-      period: 1w 
+      period: 1w
       prefix: cortex_index_
     # Chunks section is optional and required only if you're not using a
     # separate object store.
     chunks:
-      period: 1w 
+      period: 1w
       prefix: cortex_chunks
     store: aws-dynamo/bigtable-hashed/cassandra/boltdb
     object_store: <above options>/s3/gcs/azure/filesystem
@@ -66,21 +66,21 @@ configs:
   - from: "2018-08-23"
     schema: v9
     chunks:
-        period: 1w 
+        period: 1w
         prefix: dev_chunks_
     index:
-        period: 1w 
+        period: 1w
         prefix: dev_index_
     store: gcp-columnkey
 
   # Starting 2018-02-13 we moved from BigTable to GCS for storing the chunks.
   - from: "2019-02-13"
     schema: v9
     chunks:
-        period: 1w 
+        period: 1w
         prefix: dev_chunks_
     index:
-        period: 1w 
+        period: 1w
         prefix: dev_index_
     object_store: gcs
     store: gcp-columnkey
@@ -90,22 +90,22 @@ configs:
   - from: "2019-02-24"
     schema: v9
     chunks:
-        period: 1w 
+        period: 1w
         prefix: dev_chunks_
     index:
-        period: 1w 
+        period: 1w
         prefix: dev_index_
     object_store: gcs
     store: bigtable-hashed
 
-  # Starting 2019-03-05 we moved from v9 schema to v10 schema. 
+  # Starting 2019-03-05 we moved from v9 schema to v10 schema.
   - from: "2019-03-05"
     schema: v10
     chunks:
-        period: 1w 
+        period: 1w
         prefix: dev_chunks_
     index:
-        period: 1w 
+        period: 1w
         prefix: dev_index_
     object_store: gcs
     store: bigtable-hashed

diff --git a/docs/configuration/single-process-config.md b/docs/configuration/single-process-config.md
@@ -63,7 +63,7 @@ schema:
     schema: v10
     index:
       prefix: index_
-      period: 1w 
+      period: 1w
 
 storage:
   boltdb:

diff --git a/docs/configuration/v1-guarantees.md b/docs/configuration/v1-guarantees.md
@@ -1,7 +1,7 @@
 ---
 title: "v1.x Guarantees"
 linkTitle: "v1.x Guarantees"
-weight: 6 
+weight: 6
 slug: v1guarantees
 ---
 

diff --git a/docs/contributing/how-to-upgrade-golang-version.md b/docs/contributing/how-to-upgrade-golang-version.md
@@ -13,8 +13,8 @@ To upgrade the Golang version:
    - Publish the new image to `quay.io` (requires a maintainer)
    - Update the Docker image tag in `.circleci/config.yml`
 2. Upgrade integration tests version
-   - Update the Golang version installed in the `integration` job in `.circleci/config.yml` 
+   - Update the Golang version installed in the `integration` job in `.circleci/config.yml`
 
 If the minimum support Golang version should be upgraded as well:
 
-1. Upgrade `go` version in `go.mod` 
+1. Upgrade `go` version in `go.mod`
diff --git a/docs/getting-started/getting-started-with-gossip-ring.md b/docs/getting-started/getting-started-with-gossip-ring.md
@@ -106,7 +106,7 @@ is annotated diff:
 
     # bind_port needs to be unique
 -   bind_port: 7946
-+   bind_port: 7948 
++   bind_port: 7948
 
 ...
 

diff --git a/docs/guides/sharded_ruler.md b/docs/guides/sharded_ruler.md
@@ -7,7 +7,7 @@ slug: ruler-sharding
 
 ## Context
 
-One option to scale the ruler is by scaling it horizontally. However, with multiple ruler instances running they will need to coordinate to determine which instance will evaluate which rule. Similar to the ingesters, the rulers establish a hash ring to divide up the responsibilities of evaluating rules. 
+One option to scale the ruler is by scaling it horizontally. However, with multiple ruler instances running they will need to coordinate to determine which instance will evaluate which rule. Similar to the ingesters, the rulers establish a hash ring to divide up the responsibilities of evaluating rules.
 
 ## Config
 

diff --git a/docs/operations/query-tee.md b/docs/operations/query-tee.md
@@ -5,7 +5,7 @@ weight: 3
 slug: query-tee
 ---
 
-The `query-tee` is a standalone service which can be used for testing purposes to compare the query performances of 2+ backend systems (ie. Cortex clusters) ingesting the same exact series. 
+The `query-tee` is a standalone service which can be used for testing purposes to compare the query performances of 2+ backend systems (ie. Cortex clusters) ingesting the same exact series.
 
 This service exposes Prometheus-compatible read API endpoints and, for each received request, performs the request against all backends tracking the response time of each backend and then sends back to the client one of the received responses.
 

diff --git a/docs/proposals/api_design.md b/docs/proposals/api_design.md
@@ -16,7 +16,7 @@ The purpose of this design document is to propose a set of standards that should
 
 ## Current Design
 
-As things currently stand, the majority of HTTP API calls exist under the `/api/prom` path prefix. This prefix is configurable. However, since this prefix is shared between all the modules which leads to conflicts if the Alertmanager is attempted to be run as as part of the single binary (#1722). 
+As things currently stand, the majority of HTTP API calls exist under the `/api/prom` path prefix. This prefix is configurable. However, since this prefix is shared between all the modules which leads to conflicts if the Alertmanager is attempted to be run as as part of the single binary (#1722).
 
 ## Proposed Design
 
@@ -35,7 +35,7 @@ Under this path prefix, Cortex will act as a Alertmanager web server. In this ca
 #### `/api/v1/*` -- The cortex API will exist under this path prefix.
 
 - `/push`
-- `/chunks` 
+- `/chunks`
 - `/rules/*`
 
 | Current             | Proposed          |
@@ -65,7 +65,7 @@ A number of endpoints currently exist that are not under the `/api/prom` prefix
 
 ### Path Versioning
 
-Cortex will utilize path based versioning similar to both Prometheus and Alertmanager. This will allow future versions of the API to be released with changes over time. 
+Cortex will utilize path based versioning similar to both Prometheus and Alertmanager. This will allow future versions of the API to be released with changes over time.
 
 ### Backwards-Compatibility
 

diff --git a/docs/proposals/receiving_metadata.md b/docs/proposals/receiving_metadata.md
@@ -11,7 +11,7 @@ slug: support-metadata-api
 - Status: Accepted
 
 ## Problem Statement
-Prometheus holds metric metadata alongside the contents of a scrape. This metadata (`HELP`, `TYPE`, `UNIT` and `METRIC_NAME`) enables [some Prometheus API](https://github.com/prometheus/prometheus/issues/6395) endpoints to output the metadata for integrations (e.g. [Grafana](https://github.com/grafana/grafana/pull/21124)) to consume it. 
+Prometheus holds metric metadata alongside the contents of a scrape. This metadata (`HELP`, `TYPE`, `UNIT` and `METRIC_NAME`) enables [some Prometheus API](https://github.com/prometheus/prometheus/issues/6395) endpoints to output the metadata for integrations (e.g. [Grafana](https://github.com/grafana/grafana/pull/21124)) to consume it.
 
 At the moment of writing, Cortex does not support the `api/v1/metadata` endpoint that Prometheus implements as metadata was never propagated via remote write. Recent [work is done in Prometheus](https://github.com/prometheus/prometheus/pull/6815/files) enables the propagation of metadata.
 
@@ -22,7 +22,7 @@ Before we delve into the solutions, let's set a baseline about how the data is r
 
 Metadata from Prometheus is sent in the same [`WriteRequest` proto message](https://github.com/prometheus/prometheus/blob/master/prompb/remote.proto) that the samples use. It is part of a different field (#3 given #2 is already [used interally](https://github.com/cortexproject/cortex/blob/master/pkg/ingester/client/cortex.proto#L36)), the data is a set identified by the metric name - that means it is aggregated across targets, and is sent all at once. Implying, Cortex will receive a single `WriteRequest` containing a set of the metadata for that instance at an specified interval.
 
-. It is also important to note that this current process is an intermediary step. Eventually, metadata in a request will be sent alongside samples and only for those included. The solutions proposed, take this nuance into account to avoid coupling between the current and future state of Prometheus, and hopefully do something now that also works for the future. 
+. It is also important to note that this current process is an intermediary step. Eventually, metadata in a request will be sent alongside samples and only for those included. The solutions proposed, take this nuance into account to avoid coupling between the current and future state of Prometheus, and hopefully do something now that also works for the future.
 
 As a reference, these are some key numbers regarding the size (and send timings) of the data at hand from our clusters at Grafana Labs: