Merge branch 'rename-online-to-web-terminal' into 'master'

Rename "Online terminal" to "Web terminal" in the documentation

## What does this MR do?

Renames online terminals to web terminals in some recently merged documentation

## Are there points in the code the reviewer needs to double check?

I think I've caught all the links

## Why was this MR needed?

We're calling it 'web terminal' in the release post, and consistency is :sparkles: 

https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/4007/diffs#note_20283597

## Screenshots (if relevant)

## Does this MR meet the acceptance criteria?

- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if it does - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

See merge request !8190

5 files changed, 18 insertions, 18 deletions

diff --git a/doc/README.md b/doc/README.md
index 8bf33cad5e4..ee69684b53b 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -34,7 +34,7 @@
 - [Integration](integration/README.md) How to integrate with systems such as JIRA, Redmine, Twitter.
 - [Issue closing pattern](administration/issue_closing_pattern.md) Customize how to close an issue from commit messages.
 - [Koding](administration/integration/koding.md) Set up Koding to use with GitLab.
-- [Online terminals](administration/integration/terminal.md) Provide terminal access to environments from within GitLab.
+- [Web terminals](administration/integration/terminal.md) Provide terminal access to environments from within GitLab.
 - [Libravatar](customization/libravatar.md) Use Libravatar instead of Gravatar for user avatars.
 - [Log system](administration/logs.md) Log system.
 - [Environment Variables](administration/environment_variables.md) to configure GitLab.
diff --git a/doc/administration/high_availability/load_balancer.md b/doc/administration/high_availability/load_balancer.md
index e61ea359a6a..1824829903c 100644
--- a/doc/administration/high_availability/load_balancer.md
+++ b/doc/administration/high_availability/load_balancer.md
@@ -50,11 +50,11 @@ Read more on high-availability configuration:
 1. [Configure NFS](nfs.md)
 1. [Configure the GitLab application servers](gitlab.md)
 
-[^1]: [Terminal support](../../ci/environments.md#terminal-support) requires
+[^1]: [Web terminal](../../ci/environments.md#web-terminals) support requires
       your load balancer to correctly handle WebSocket connections. When using
       HTTP or HTTPS proxying, this means your load balancer must be configured
       to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the
-      [online terminal](../integration/terminal.md) integration guide for
+      [web terminal](../integration/terminal.md) integration guide for
       more details.
 [^2]: When using HTTPS protocol for port 443, you will need to add an SSL
       certificate to the load balancers. If you wish to terminate SSL at the
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md
index 05d0a97e554..a1d1bb03b50 100644
--- a/doc/administration/integration/terminal.md
+++ b/doc/administration/integration/terminal.md
@@ -1,17 +1,17 @@
-# Online terminals
+# Web terminals
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7690)
-in GitLab 8.15. Only project masters and owners can access online terminals.
+in GitLab 8.15. Only project masters and owners can access web terminals.
 
 With the introduction of the [Kubernetes](../../project_services/kubernetes.md)
 project service, GitLab gained the ability to store and use credentials for a
 Kubernetes cluster. One of the things it uses these credentials for is providing
-access to [online terminals](../../ci/environments.html#online-terminals)
+access to [web terminals](../../ci/environments.html#web-terminals)
 for environments.
 
 ## How it works
 
-A detailed overview of the architecture of online terminals and how they work
+A detailed overview of the architecture of web terminals and how they work
 can be found in [this document](https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/doc/terminal.md).
 In brief:
 
@@ -31,7 +31,7 @@ In brief:
 
 ##  Enabling and disabling terminal support
 
-As online terminals use WebSockets, every HTTP/HTTPS reverse proxy in front of
+As web terminals use WebSockets, every HTTP/HTTPS reverse proxy in front of
 Workhorse needs to be configured to pass the `Connection` and `Upgrade` headers
 through to the next one in the chain. If you installed Gitlab using Omnibus, or
 from source, starting with GitLab 8.15, this should be done by the default
@@ -56,7 +56,7 @@ Omnibus installation before upgrading to 8.15, you may need to make some
 changes to your configuration. See the  [8.14 to 8.15 upgrade](../../update/8.14-to-8.15.md#nginx-configuration)
 document for more details.
 
-If you'd like to disable online terminal support in GitLab, just stop passing
+If you'd like to disable web terminal support in GitLab, just stop passing
 the `Connection` and `Upgrade` hop-by-hop headers in the *first* HTTP reverse
 proxy in the chain. For most users, this will be the NGINX server bundled with
 Omnibus Gitlab, in which case, you need to:
@@ -69,5 +69,5 @@ For your own load balancer, just reverse the configuration changes recommended
 by the above guides.
 
 When these headers are not passed through, Workhorse will return a
-`400 Bad Request` response to users attempting to use an online terminal. In
-turn, they will receive a `Connection failed` message.
+`400 Bad Request` response to users attempting to use a web terminal. In turn,
+they will receive a `Connection failed` message.
diff --git a/doc/ci/environments.md b/doc/ci/environments.md
index 07d92bb746c..98cd29c9567 100644
--- a/doc/ci/environments.md
+++ b/doc/ci/environments.md
@@ -27,7 +27,7 @@ so every environment can have one or more deployments. GitLab keeps track of
 your deployments, so you always know what is currently being deployed on your
 servers. If you have a deployment service such as [Kubernetes][kubernetes-service]
 enabled for your project, you can use it to assist with your deployments, and
-can even access a terminal for your environment from within GitLab!
+can even access a web terminal for your environment from within GitLab!
 
 To better understand how environments and deployments work, let's consider an
 example. We assume that you have already created a project in GitLab and set up
@@ -235,10 +235,10 @@ Remember that if your environment's name is `production` (all lowercase), then
 it will get recorded in [Cycle Analytics](../user/project/cycle_analytics.md).
 Double the benefit!
 
-## Terminal support
+## Web terminals
 
 >**Note:**
-Terminal support was added in GitLab 8.15 and is only available to project
+Web terminals were added in GitLab 8.15 and are only available to project
 masters and owners.
 
 If you deploy to your environments with the help of a deployment service (e.g.,
diff --git a/doc/project_services/kubernetes.md b/doc/project_services/kubernetes.md
index 0c5c88dd983..59d5da702f8 100644
--- a/doc/project_services/kubernetes.md
+++ b/doc/project_services/kubernetes.md
@@ -48,16 +48,16 @@ GitLab CI build environment:
 - `KUBE_NAMESPACE`
 - `KUBE_CA_PEM` - only if a custom CA bundle was specified
 
-## Terminal support
+## Web terminals
 
 >**NOTE:**
 Added in GitLab 8.15. You must be the project owner or have `master` permissions
 to use terminals. Support is currently limited to the first container in the
 first pod of your environment.
 
-When enabled, the Kubernetes service adds online [terminal support](../ci/environments.md#terminal-support)
-to your environments. This is based on the `exec` functionality found in
+When enabled, the Kubernetes service adds [web terminal](../ci/environments.md#web-terminals)
+support to your environments. This is based on the `exec` functionality found in
 Docker and Kubernetes, so you get a new shell session within your existing
 containers. To use this integration, you should deploy to Kubernetes using
 the deployment variables above, ensuring any pods you create are labelled with
-`app=$CI_ENVIRONMENT_SLUG`.
+`app=$CI_ENVIRONMENT_SLUG`. GitLab will do the rest!