Apply name changes to Fleet docs (#165) (#194)

* Apply naming changes to fleet docs

* Add redirects

* Change guide name

Author: dedemorton

docs/en/ingest-management/faq.asciidoc

@@ -12,9 +12,9 @@ Also read <<ingest-management-troubleshooting>>.
 
 [discrete]
 [[enrolled-agent-not-showing-up]]
-== Why doesn't my enrolled Agent show up in the {ingest-manager} app?
+== Why doesn't my enrolled agent show up in the {fleet} app?
 
-If {agent} was successfully enrolled, but doesn't show up in the {fleet} list,
+If {agent} was successfully enrolled, but doesn't show up in the *Agents* list,
 it might not be started. You need to <<run-elastic-agent,start {agent}>>.
 
 [discrete]
@@ -28,9 +28,9 @@ higher level problem to triage.
 
 [discrete]
 [[what-is-my-agent-config]]
-== What configuration is the {agent} running?
+== What policy is the {agent} running?
 
-To find the configuration file, inspect the `elastic-agent.yml` file in the
+To find the policy file, inspect the `elastic-agent.yml` file in the
 folder where you ran {agent}. If you're running the agent in {fleet} mode, this
 file contains the following citation:
 
@@ -39,13 +39,13 @@ file contains the following citation:
 Management: mode: "fleet"
 ----
 
-The `action_store.yml` contains the entire, unencrypted configuration:
+The `action_store.yml` contains the entire, unencrypted policy:
 
 * To see the {es} location, look at `outputs:hosts`.
 * To see the {agent} version, look at the download folder and zip filenames.
 
 This file also shows the version of all packages used by the current
-configuration.
+policy.
 
 [discrete]
 [[where-is-the-data-agent-is-sending]]
@@ -110,7 +110,7 @@ available in a future release.
 == Does {agent} or {kib} download integration packages?
 
 {agent} does not download integration packages. When you add an integration in
-{ingest-manager}, {kib} connects to the {package-registry} at `epr.elastic.co`,
+{fleet}, {kib} connects to the {package-registry} at `epr.elastic.co`,
 downloads the integration package, and stores its assets in {es}. This means
 that you no longer have to run a manual setup command to load integrations as
 you did previously with {beats} modules.
@@ -140,7 +140,7 @@ command on the host to load assets, such as ingest pipelines and dashboards. In
 contrast, {beats} managed by {agent} use integration packages that {kib}
 downloads from the {package-registry} at `epr.elastic.co`. This means that
 {agent} does not need extra privileges to set up assets because
-{ingest-manager} manages the assets.
+{fleet} manages the assets.
 
 [discrete]
 [[what-is-the-endpoint-package]]

docs/en/ingest-management/ingest-management-limitations.asciidoc renamed to docs/en/ingest-management/fleet-limitations.asciidoc

@@ -1,12 +1,12 @@
-[[ingest-management-limitations]]
+[[fleet-limitations]]
 [role="xpack"]
 = Limitations of this release
 
 beta[]
 
-{ingest-manager} is currently only available to users with the
+{fleet} is currently only available to users with the
 {ref}/built-in-roles.html[superuser role]. This role is necessary to create
-indices, install integration assets, and update {agent} configurations. In order
+indices, install integration assets, and update {agent} policies. In order
 to use {fleet}, the {agent}s must have a direct network connection to {kib} and
 {es}. It is also possible to run the {agent}s in standalone mode in cases where
 a network connection is not available or not needed.

docs/en/ingest-management/ingest-management-overview.asciidoc renamed to docs/en/ingest-management/fleet-overview.asciidoc

@@ -1,6 +1,6 @@
-[[ingest-management-overview]]
+[[fleet-overview]]
 [role="xpack"]
-= Ingest management overview
+= Overview
 
 beta[]
 
@@ -11,13 +11,13 @@ beta[]
 {agent} is a single, unified way to add monitoring for logs, metrics, and
 other types of data to each host. A single agent makes it easier and faster
 to deploy monitoring across your infrastructure. The agent's single, unified
-configuration makes it easier to add integrations for new data sources.
+policy makes it easier to add integrations for new data sources.
 
 [discrete]
-[[ingest-manager]]
-== {ingest-manager}
+[[fleet]]
+== {fleet}
 
-{ingest-manager} provides a web-based UI in {kib} to add and manage integrations
+{fleet} provides a web-based UI in {kib} to add and manage integrations
 for popular services and platforms, as well as manage a fleet of {agent}s. Our
 integrations provide an easy way to add new sources of data, plus they ship
 with out-of-the-box assets like dashboards, visualizations, and pipelines to
@@ -29,50 +29,51 @@ image::images/integrations.png[Integrations page]
 
 [discrete]
 [[configuring-integrations]]
-== {integrations} in {ingest-manager}
+== {integrations} in {fleet}
 
-{ingest-manager} provides a web-based UI for configuring integrations with your
+{fleet} provides a web-based UI for configuring integrations with your
 data sources. This includes popular services and platforms like Nginx or AWS,
 as well as many generic input types like log files.
 
-The {agent} configuration allows you to use any number of integrations for
-data sources. You can apply the {agent} configuration to multiple agents,
+The {agent} policy allows you to use any number of integrations for
+data sources. You can apply the {agent} policy to multiple agents,
 making it even easier to manage configuration at scale.
 
 [role="screenshot"]
 image::images/add-integration.png[Add integration page]
 
-When you add an integration, you select the agent configuration to use then
+When you add an integration, you select the agent policy to use then
 configure inputs for logs and metrics, such as the path to your Nginx access
 logs. When you're done, you save the integration to update the {agent}
-configuration. The next time enrolled agents check in, they receive the update.
-Having the configurations automatically deployed is more convenient
+policy. The next time enrolled agents check in, they receive the update.
+Having the policies automatically deployed is more convenient
 than doing it yourself by using SSH, Ansible playbooks, or some other tool.
 
 If you prefer infrastructure as code, you may use YAML files and APIs.
-{ingest-manager} has an API-first design. Anything you can do in the UI, you
+{fleet} has an API-first design. Anything you can do in the UI, you
 can also do using the API. This makes it easy to automate and integrate with
 other systems.
 
 [discrete]
 [[central-management]]
 == Central management in {fleet}
 
-You can see the state of all your {agent}s on the {fleet} page. Here you can see
-which agents are online, which have errors, and the last time they checked in.
-You can also see the version of the {agent} binary and configuration. 
+You can see the state of all your {agent}s in {fleet}. On the **Agents** page,
+you can see which agents are online, which have errors, and the last time
+they checked in. You can also see the version of the {agent} binary and
+policy.
 
-//TODO: Replace this screen after testing (to show a number of agents).
+//TODO: Replace this screenshot with one that shows more than one agent.
 
 [role="screenshot"]
-image::images/fleet.png[{fleet} page]
+image::images/kibana-fleet-agents.png[Agents page] 
 
 {fleet} serves as the communication channel back to the {agent}s. Agents check
 in for the latest updates on a regular basis. You can have any number of agents
-enrolled into each agent configuration, which allows you to scale up to
-thousands of hosts. When you make a change to an agent configuration, all the
+enrolled into each agent policy, which allows you to scale up to
+thousands of hosts. When you make a change to an agent policy, all the
 agents receive the update during their next check-in. You no longer have to
-distribute configuration updates yourself.
+distribute policy updates yourself.
 
 [discrete]
 [[data-streams]]
@@ -86,8 +87,12 @@ permissions. These indices are called _data streams_.
 As you can see in the following screen, each data stream (or index) is broken
 out by dataset, type, and namespace. 
 
+// REVIEWERS: Have I gotten the terminology right here? It sounds
+// like datasets is still a concept, but when we talk about the indices created
+// here, they are data streams. Is that correct?
+
 [role="screenshot"]
-image::images/datasets.png[Datasets page]
+image::images/kibana-fleet-datastreams.png[Data streams page]
 
 The _dataset_ is defined by the integration and describes the fields and other
 settings for each index. For example, you might have one dataset for process