Remove mentions of sozuctl

Author: GuillaumeASSIER

CONTRIBUTING.md

@@ -18,11 +18,10 @@ The proxy is designed to have a minimal core that you drive through external too
 There are 4 Rust crates in the repository:
 
 - `lib` is the event loop handling network communication and parsing. Workers are small wrappers around this
-- `bin` is the main executable, providing a master/workers multiprocess architecture and exposing a unix socket to receive configuration changes
+- `bin` is the main executable, providing a master/workers multiprocess architecture and exposing a unix socket to receive configuration changes. It also contains the command line.
 - `command` is a library wrapping the communication protocol of the unix socket. You'd typically use it to make tools to drive the proxy
-- `ctl` is the `sozuctl` command line application provided with the proxy, to interact with it at runtime
 
-The easiest way to contribute would be to work on `sozuctl` or on external tools
+The easiest way to contribute would be to work on the command line (`cli.rs`) or on external tools
 using the `command` library. `lib` can be complex since you need familiarity with
 the event loop handling, but the parsers and protocol are well separated. `bin` is
 mostly plumbing to handle command line options, handle workers and dispatching

README.md

@@ -21,7 +21,7 @@ To get started check out our [documentation](./doc/README.md) !
 
 Copyright (C) 2015-2021 Geoffroy Couprie, Clément Delafargue and Clever Cloud
 
-### sozu-lib, sozu and sozuctl
+### sozu-lib, sozu
 
 This program is free software: you can redistribute it and/or modify it under
 the terms of the GNU Affero General Public License as published by the Free

bin/config.toml

@@ -4,7 +4,7 @@
 
 # path to a file sozu can use to load an initial configuration state for its
 # routing. You can generate this file from sozu's current routing by running
-# the command `sozuctl state save -f state.json`
+# the command `sozu state save -f state.json`
 # this must be RELATIVE to config.toml
 # saved_state = "./state.json"
 
@@ -87,7 +87,7 @@ max_connections = 500
 # defaults to 16393 (minimum size for HTTP/2 is a 16384 bytes frame + 9 bytes of header
 buffer_size = 16393
 
-# how much time (in milliseconds) sozuctl will wait for a command to complete.
+# how much time (in milliseconds) sozu command line will wait for a command to complete.
 # Defaults to 1000 milliseconds
 # ctl_command_timeout = 1000
 
@@ -127,8 +127,8 @@ buffer_size = 16393
 activate_listeners = true
 
 # various statistics can be sent to a server that supports the statsd protocol
-# You can see those statistics with sozuctl, like this: `sozuctl metrics` or
-# `sozuctl metrics --json` for machine consumption
+# You can see those statistics with the command line, like this: `sozu metrics get` or
+# `sozu metrics get --json` for machine consumption
 #
 #[metrics]
 # address = "127.0.0.1:8125"

bin/src/cli.rs

@@ -92,7 +92,7 @@ pub enum SubCmd {
         max_command_buffer_size: Option<usize>,
     },
 
-    // sozuctl commands
+    // sozu command line
     #[clap(name = "shutdown", about = "shuts down the proxy")]
     Shutdown {
         #[clap(long = "hard", help = "do not wait for connections to finish")]

doc/configure.md

@@ -22,7 +22,7 @@ Parameters in the global section allow you to define the global settings shared
 | `log_level`                | possible values are                                                                 | `debug`, `trace`, `error`, `warn`, `info`|
 | `log_target`               | possible values are                                                                 | `stdout, tcp or udp address`             |
 | `log_access_target`        | possible values are (if activated, sends access logs to a separate target)          | `stdout`, `tcp` or `udp address`         |
-| `command_socket`           | path to the unix socket command (see sozuctl for more information)                  |                                          |
+| `command_socket`           | path to the unix socket command                  |                                          |
 | `command_buffer_size`      | size, in bytes, of the buffer used by the main process to handle commands.          |                                          |
 | `max_command_buffer_size`  | maximum size of the buffer used by the main process to handle commands.             |                                          |
 | `worker_count`             | number of workers                                                                   |                                          |
@@ -32,7 +32,7 @@ Parameters in the global section allow you to define the global settings shared
 | `max_buffers`              | maximum number of buffers use to proxying                                           |                                          |
 | `min_buffers`              | minimum number of buffers preallocated for proxying                                 |                                          |
 | `buffer_size`              | size, in bytes, of requests buffer use by the workers                               |                                          |
-| `ctl_command_timeout`      | maximum time sozuctl will wait for a command to complete                            |                                          |
+| `ctl_command_timeout`      | maximum time the command line will wait for a command to complete                            |                                          |
 | `pid_file_path`            | stores the pid in a specific file location                                          |                                          |
 | `front_timeout`            | maximum time of inactivity for a front socket                                       |                                          |
 | `connect_timeout`          | maximum time of inactivity for a request to connect                                 |                                          |

doc/debugging_strategies.md

@@ -4,7 +4,7 @@ Sozu provides logs and metrics allowing detection of most production issues.
 
 ## Gathering information
 
-### Dumping the state through sozuctl
+### Dumping the state through sozu command line
 
 It is useful to gather information on the configuration state in a production system.
 Here are some commands you can use to take a snapshot of the current state:
@@ -39,7 +39,7 @@ unless you set the compilation features `logs-debug` and `logs-trace`.
 
 Various metrics are generated while sozu is running. They can be accessed in two ways:
 
-* through `sozuctl metrics`, which will display metrics for the main process and workers. Counters are refreshed between each call
+* through `sozu metrics get`, which will display metrics for the main process and workers. Counters are refreshed between each call
 * by UDP, following the statsd protocol (optionally with support for InfluxDB's tags)
 
 Here is how you can set up metrics with statsd in the configuration file:
@@ -232,13 +232,13 @@ Normal traffic (`sozu.http.requests`) drops while 404 (`sozu.http.404.errors`) a
 Check the configuration state with;
 
 ```bash
-sozuctl -c /etc/config.toml query clusters
+sozu -c /etc/config.toml query clusters
 ```
 
 And, for the complete configuration for a specific cluster id:
 
 ```bash
-sozuctl -c /etc/config.toml query clusters -i cluster_id
+sozu -c /etc/config.toml query clusters -i cluster_id
 ```
 
 ### Backend server unavailable

doc/getting_started.md

@@ -9,15 +9,11 @@ After you did that, `Rust` should be fully installed.
 
 ## Setting up Sōzu
 
-### Required dependencies
-
-- libssl-dev
-
 ### Install
 
 `sozu` is published on [crates.io][cr].
 
-To install them, you only have to do `cargo install sozu sozuctl`.
+To install them, you only have to do `cargo install sozu`.
 
 They will be built and available in the `~/.cargo/bin` folder.
 

doc/how_to_use.md

@@ -4,11 +4,11 @@
 
 ## Run it
 
-If you used the `cargo install` way, `sozu` and `sozuctl` are already in your `$PATH`.
+If you used the `cargo install` way, `sozu` is already in your `$PATH`.
 
 `sozu start -c <path/to/your/config.toml>`
 
-However, if you built the project from source, `sozu` and `sozuctl` are placed in the `target` directory.
+However, if you built the project from source, `sozu` is placed in the `target` directory.
 
 `./target/release/sozu start -c <path/to/your/config.toml>`
 
@@ -66,9 +66,9 @@ If `/my/custom/config.toml` is the path and name of your custom configuration fi
 
 `docker run -v /my/custom:/etc/sozu sozu`
 
-### Using sozuctl with the docker container
+### Using sozu command line with the docker container
 
-To use `sozuctl` CLI from the host with the docker container you have to bind `/run/sozu` with the host by using a docker volume:
+To use `sozu` CLI from the host with the docker container you have to bind `/run/sozu` with the host by using a docker volume:
 
 `docker run -v /run/sozu:/run/sozu sozu`
 

doc/managing_workers.md

@@ -7,7 +7,7 @@ How do we solve this challenge? Unix sockets and channels.
 
 ## Architecture
 
-`sozuctl` sends commands on a unix socket.
+`sozu` command line sends commands on a unix socket.
 In the `command::start_server()` function of the main process,
 there is a thread running in the background where a unix listener accepts new
 connection and spawns client loops.

doc/recipes.md

@@ -30,7 +30,7 @@ Wants=network-online.target
 
 [Service]
 ExecStart=/usr/bin/sozu start --config /etc/sozu/config.toml
-ExecReload=/usr/bin/sozuctl --config /etc/sozu/config.toml reload
+ExecReload=/usr/bin/sozu --config /etc/sozu/config.toml reload
 Restart=on-failure
 User=sozu
 AmbientCapabilities=CAP_NET_BIND_SERVICE