docs: update references to fleetd

Documentation/architecture.md

@@ -1,6 +1,6 @@
 # Architecture
 
-There exist two primary roles within fleet: Engine and Agent. Each `fleet` daemon running in a cluster fulfills both roles. An Engine primarily makes scheduling decisions while an Agent executes jobs.
+There exist two primary roles within fleet: Engine and Agent. Each `fleetd` daemon running in a cluster fulfills both roles. An Engine primarily makes scheduling decisions while an Agent executes jobs.
 
 ## Moving Parts
 

Documentation/configuration.md

@@ -1,18 +1,18 @@
 # Configuration
 
-The `fleet` daemon uses two sources for configuration parameters:
+The `fleetd` daemon uses two sources for configuration parameters:
 
 1. an INI-formatted config file ([sample][config])
 2. environment variables
 
 [config]: https://github.com/coreos/fleet/blob/master/fleet.conf.sample
 
-fleet will look at `/etc/fleet/fleet.conf` for this config file by default. The `--config` flag may be passed to the fleet binary to use a custom config file location. The options that may be set are defined below. Note that each of the options should be defined at the global level, outside of any INI sections.
+fleet will look at `/etc/fleet/fleet.conf` for this config file by default. The `--config` flag may be passed to the `fleetd` binary to use a custom config file location. The options that may be set are defined below. Note that each of the options should be defined at the global level, outside of any INI sections.
 
-Environment variables may also provide configuration options. Options provided in an environment variable will override the corresponding option provided in a config file. To use an environment variable, simply prefix the name of a given option with 'FLEET_', while uppercasing the rest of the name. For example, to set the `etcd_servers` option to 'http://192.0.2.12:4001' when running the fleet binary:
+Environment variables may also provide configuration options. Options provided in an environment variable will override the corresponding option provided in a config file. To use an environment variable, simply prefix the name of a given option with 'FLEET_', while uppercasing the rest of the name. For example, to set the `etcd_servers` option to 'http://192.0.2.12:4001' when running the fleetd binary:
 
 ```
-$ FLEET_ETCD_SERVERS=http://192.0.2.12:4001 /usr/bin/fleet
+$ FLEET_ETCD_SERVERS=http://192.0.2.12:4001 /usr/bin/fleetd
 ```
 
 ## General Options
@@ -44,7 +44,7 @@ Default: ""
 #### public_ip
 
 IP address that should be published with the local Machine's state and any socket information.
-If not set, fleet will attempt to detect the IP it should publish based on the machine's IP routing information.
+If not set, fleetd will attempt to detect the IP it should publish based on the machine's IP routing information.
 
 Default: ""
 

Documentation/deployment.md

@@ -1,12 +1,12 @@
 # Deploying fleet
 
-Deploying `fleet` is as simple as dropping a binary on a machine with access to etcd and starting it.
+Deploying `fleet` is as simple as dropping the `fleetd` binary on a machine with access to etcd and starting it.
 
 Deploying `fleet` on CoreOS is even simpler: just run `systemctl start fleet`. The built-in configuration assumes each of your hosts is serving an etcd endpoint at the default location (http://127.0.0.1:4001). However, if your etcd cluster differs, you must make the corresponding configuration changes.
 
 ### etcd
 
-Each `fleet` daemon must be configured to talk to the same [etcd cluster][etcd]. By default, the `fleet` daemon will connect to http://127.0.0.1:4001. Refer to the [configuration documentation][config] for customization help.
+Each `fleetd` daemon must be configured to talk to the same [etcd cluster][etcd]. By default, the `fleetd` daemon will connect to http://127.0.0.1:4001. Refer to the [configuration documentation][config] for customization help.
 
 `fleet` requires etcd be of version 0.3.0+.
 
@@ -15,7 +15,7 @@ Each `fleet` daemon must be configured to talk to the same [etcd cluster][etcd].
 
 ### systemd
 
-The `fleet` daemon communicates with systemd (v207+) running locally on a given machine. It requires D-Bus (v1.6.12+) to do this.
+The `fleetd` daemon communicates with systemd (v207+) running locally on a given machine. It requires D-Bus (v1.6.12+) to do this.
 
 ### SSH Keys
 

Documentation/security.md

@@ -11,6 +11,6 @@ You should avoid public access to the registry (i.e etcd) and instead run fleet
 
 ## Other Notes
 
-Since it interacts directly with systemd over D-Bus, the fleet daemon must be run with elevated privileges (i.e. as root) in order to perform operations like starting and stopping services. From the [systemd D-Bus documentation](http://www.freedesktop.org/wiki/Software/systemd/dbus/):
+Since it interacts directly with systemd over D-Bus, the fleetd daemon must be run with elevated privileges (i.e. as root) in order to perform operations like starting and stopping services. From the [systemd D-Bus documentation](http://www.freedesktop.org/wiki/Software/systemd/dbus/):
 
 > In contrast to most of the other services of the systemd suite PID 1 does not use PolicyKit for controlling access to privileged operations, but relies exclusively on the low-level D-Bus policy language. (This is done in order to avoid a cyclic dependency between PolicyKit and systemd/PID 1.) This means that sensitive operations exposed by PID 1 on the bus are generally not available to unprivileged processes directly.