cmd: Moved all no-service commands under new tools subcommand.

This will allow better extensibility for future for non-bucket related tools we plan to add.

Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>

CHANGELOG.md

@@ -22,7 +22,8 @@ We use *breaking* word for marking changes that are not backward compatible (rel
 ### Changed
 
 - [#2505](https://github.com/thanos.io/thanos/pull/2505) Store: remove obsolete `thanos_store_node_info` metric.
-- [#2508](https://github.com/thanos.io/thanos/pull/2508) Dockerfile: Leveraging docker layer caching.
+- [2513](https://github.com/thanos-io/thanos/pull/2513) Tools: Moved `thanos bucket` commands to `thanos tools bucket`, also
+moved `thanos check rules` to `thanos tools rules-check`.
 
 ## [v0.12.1](https://github.com/thanos-io/thanos/releases/tag/v0.12.1) - 2020.04.20
 

cmd/thanos/main.go

@@ -60,9 +60,8 @@ func main() {
 	registerQuery(cmds, app)
 	registerRule(cmds, app)
 	registerCompact(cmds, app)
-	registerBucket(cmds, app, "bucket")
+	registerTools(cmds, app)
 	registerReceive(cmds, app)
-	registerChecks(cmds, app, "check")
 
 	cmd, err := app.Parse(os.Args[1:])
 	if err != nil {

cmd/thanos/check.go → cmd/thanos/tools.go

@@ -17,19 +17,21 @@ import (
 	"gopkg.in/yaml.v2"
 )
 
-func registerChecks(m map[string]setupFunc, app *kingpin.Application, name string) {
-	cmd := app.Command(name, "Linting tools for Thanos")
-	registerCheckRules(m, cmd, name)
+func registerTools(m map[string]setupFunc, app *kingpin.Application) {
+	cmd := app.Command("tools", "Tools utility commands")
+
+	registerBucket(m, cmd, "tools")
+	registerCheckRules(m, cmd, "tools")
 }
 
-func registerCheckRules(m map[string]setupFunc, root *kingpin.CmdClause, name string) {
-	checkRulesCmd := root.Command("rules", "Check if the rule files are valid or not.")
+func registerCheckRules(m map[string]setupFunc, app *kingpin.CmdClause, pre string) {
+	checkRulesCmd := app.Command("rules-check", "Check if the rule files are valid or not.")
 	ruleFiles := checkRulesCmd.Arg(
 		"rule-files",
 		"The rule files to check.",
 	).Required().ExistingFiles()
 
-	m[name+" rules"] = func(g *run.Group, logger log.Logger, reg *prometheus.Registry, _ opentracing.Tracer, _ <-chan struct{}, _ bool) error {
+	m[pre+" rules-check"] = func(g *run.Group, logger log.Logger, reg *prometheus.Registry, _ opentracing.Tracer, _ <-chan struct{}, _ bool) error {
 		// Dummy actor to immediately kill the group after the run function returns.
 		g.Add(func() error { return nil }, func(error) {})
 		return checkRulesFiles(logger, ruleFiles)

cmd/thanos/bucket.go → cmd/thanos/tools_bucket.go

@@ -64,16 +64,17 @@ var (
 	inspectColumns = []string{"ULID", "FROM", "UNTIL", "RANGE", "UNTIL-DOWN", "#SERIES", "#SAMPLES", "#CHUNKS", "COMP-LEVEL", "COMP-FAILED", "LABELS", "RESOLUTION", "SOURCE"}
 )
 
-func registerBucket(m map[string]setupFunc, app *kingpin.Application, name string) {
-	cmd := app.Command(name, "Bucket utility commands")
+func registerBucket(m map[string]setupFunc, app *kingpin.CmdClause, pre string) {
+	cmd := app.Command("bucket", "Bucket utility commands")
 
+	pre += " bucket"
 	objStoreConfig := regCommonObjStoreFlags(cmd, "", true)
-	registerBucketVerify(m, cmd, name, objStoreConfig)
-	registerBucketLs(m, cmd, name, objStoreConfig)
-	registerBucketInspect(m, cmd, name, objStoreConfig)
-	registerBucketWeb(m, cmd, name, objStoreConfig)
-	registerBucketReplicate(m, cmd, name, objStoreConfig)
-	registerBucketDownsample(m, cmd, name, objStoreConfig)
+	registerBucketVerify(m, cmd, pre, objStoreConfig)
+	registerBucketLs(m, cmd, pre, objStoreConfig)
+	registerBucketInspect(m, cmd, pre, objStoreConfig)
+	registerBucketWeb(m, cmd, pre, objStoreConfig)
+	registerBucketReplicate(m, cmd, pre, objStoreConfig)
+	registerBucketDownsample(m, cmd, pre, objStoreConfig)
 }
 
 func registerBucketVerify(m map[string]setupFunc, root *kingpin.CmdClause, name string, objStoreConfig *extflag.PathOrContent) {

cmd/thanos/check_test.go → cmd/thanos/tools_test.go

@@ -10,7 +10,7 @@ import (
 	"github.com/thanos-io/thanos/pkg/testutil"
 )
 
-func Test_checkRules(t *testing.T) {
+func Test_CheckRules(t *testing.T) {
 
 	validFiles := []string{
 		"./testdata/rules-files/valid.yaml",

docs/components/compact.md

@@ -6,7 +6,7 @@ menu: components
 
 # Compactor
 
-The compactor component of Thanos applies the compaction procedure of the Prometheus 2.0 storage engine to block data stored in object storage.
+The `thanos compact` command applies the compaction procedure of the Prometheus 2.0 storage engine to block data stored in object storage.
 It is generally not semantically concurrency safe and must be deployed as a singleton against a bucket.
 
 It is also responsible for downsampling of data:
@@ -17,7 +17,7 @@ It is also responsible for downsampling of data:
 Example:
 
 ```bash
-$ thanos compact --data-dir /tmp/thanos-compact --objstore.config-file=bucket.yml
+thanos compact --data-dir /tmp/thanos-compact --objstore.config-file=bucket.yml
 ```
 
 The content of `bucket.yml`:

docs/components/query.md

@@ -6,7 +6,7 @@ menu: components
 
 # Querier/Query
 
-The Querier component (also known as "Query") implements the [Prometheus HTTP v1 API](https://prometheus.io/docs/prometheus/latest/querying/api/) to query data in a Thanos cluster via PromQL.
+The `thanos query` command (also known as "Querier") implements the [Prometheus HTTP v1 API](https://prometheus.io/docs/prometheus/latest/querying/api/) to query data in a Thanos cluster via PromQL.
 
 In short, it gathers the data needed to evaluate the query from underlying [StoreAPIs](../../pkg/store/storepb/rpc.proto), evaluates the query and returns the result.
 
@@ -15,7 +15,7 @@ Querier is fully stateless and horizontally scalable.
 Example command to run Querier:
 
 ```bash
-$ thanos query \
+thanos query \
     --http-address     "0.0.0.0:9090" \
     --store            "<store-api>:<grpc-port>" \
     --store            "<store-api2>:<grpc-port>"
@@ -81,7 +81,7 @@ This also hides gaps in collection of a single data source.
 If we configure Querier like this:
 
 ```
-$ thanos query \
+thanos query \
     --http-address        "0.0.0.0:9090" \
     --query.replica-label "replica" \
     --store               "<store-api>:<grpc-port>" \
@@ -106,7 +106,7 @@ WITHOUT this replica flag (deduplication turned off), we will get 3 results:
 * Prometheus + sidecar "A" in different cluster: `cluster=2,env=2,replica=A,replicaX=A`
 
 ```
-$ thanos query \
+thanos query \
     --http-address        "0.0.0.0:9090" \
     --query.replica-label "replica" \
     --query.replica-label "replicaX" \

docs/components/rule.md

@@ -10,7 +10,7 @@ _**NOTE:** It is recommended to keep deploying rules inside the relevant Prometh
 
 _The rule component should in particular not be used to circumvent solving rule deployment properly at the configuration management level._
 
-The rule component evaluates Prometheus recording and alerting rules against chosen query API via repeated `--query` (or FileSD via `--query.sd`). If more than one query is passed, round robin balancing is performed.
+The `thanos rule` command evaluates Prometheus recording and alerting rules against chosen query API via repeated `--query` (or FileSD via `--query.sd`). If more than one query is passed, round robin balancing is performed.
 
 Rule results are written back to disk in the Prometheus 2.0 storage format. Rule nodes at the same time participate in the system as source store nodes, which means that they expose StoreAPI and upload their generated TSDB blocks to an object store.
 
@@ -20,7 +20,7 @@ The data of each Rule node can be labeled to satisfy the clusters labeling schem
 Read more about Ruler in HA [here](rule.md#ruler-ha)
 
 ```bash
-$ thanos rule \
+thanos rule \
     --data-dir             "/path/to/data" \
     --eval-interval        "30s" \
     --rule-file            "/path/to/rules/*.rules.yaml" \

docs/components/sidecar.md

@@ -6,7 +6,7 @@ menu: components
 
 # Sidecar
 
-The sidecar component of Thanos gets deployed along with a Prometheus instance. This allows sidecar to optionally upload metrics to object storage and allow [Queriers](./query.md) to query Prometheus data with common, efficient StoreAPI.
+The `thanos sidecar` command runs a component that gets deployed along with a Prometheus instance. This allows sidecar to optionally upload metrics to object storage and allow [Queriers](./query.md) to query Prometheus data with common, efficient StoreAPI.
 
 In details:
 
@@ -49,14 +49,14 @@ Thanos sidecar can watch `--reloader.config-file=CONFIG_FILE` configuration file
 ## Example basic deployment
 
 ```bash
-$ prometheus \
+prometheus \
   --storage.tsdb.max-block-duration=2h \
   --storage.tsdb.min-block-duration=2h \
   --web.enable-lifecycle
 ```
 
 ```bash
-$ thanos sidecar \
+thanos sidecar \
     --tsdb.path        "/path/to/prometheus/data/dir" \
     --prometheus.url   "http://localhost:9090" \
     --objstore.config-file  "bucket.yml"

docs/components/store.md

@@ -6,11 +6,11 @@ menu: components
 
 # Store
 
-The store component of Thanos implements the Store API on top of historical data in an object storage bucket. It acts primarily as an API gateway and therefore does not need significant amounts of local disk space. It joins a Thanos cluster on startup and advertises the data it can access.
+The `thanost store` command (also known as Store Gateway) implements the Store API on top of historical data in an object storage bucket. It acts primarily as an API gateway and therefore does not need significant amounts of local disk space. It joins a Thanos cluster on startup and advertises the data it can access.
 It keeps a small amount of information about all remote blocks on local disk and keeps it in sync with the bucket. This data is generally safe to delete across restarts at the cost of increased startup times.
 
 ```bash
-$ thanos store \
+thanos store \
     --data-dir        "/local/state/data/dir" \
     --objstore.config-file "bucket.yml"
 ```
@@ -28,7 +28,6 @@ In general about 1MB of local disk space is required per TSDB block stored in th
 ## Flags
 
 [embedmd]: # "flags/store.txt $"
-
 ```$
 usage: thanos store [<flags>]