Change references from Docker to Container.

Docker container -> container

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>

Author: rhatdan

HACKING.md

@@ -200,7 +200,7 @@ costly setup those components should be tested in isolation.
 
 We break integration tests into two categories, those that use Docker and those
 that do not.  In general, high-level components that depend on the behavior of code
-running inside a Docker container should have at least one or two integration tests
+running inside a container should have at least one or two integration tests
 that test all the way down to Docker, but those should be part of their own
 test suite.  Testing the API and high-level API functions should generally
 not depend on calling into Docker. They are denoted by special test tags and

README.md

@@ -50,7 +50,7 @@ The latest OKD Origin images are published to the Docker Hub under the `openshif
 
 ### Concepts
 
-OKD builds a developer-centric workflow around Docker containers and Kubernetes runtime concepts.  An **Image Stream** lets you easily tag, import, and publish Docker images from the integrated registry.  A **Build Config** allows you to launch Docker builds, build directly from source code, or trigger Jenkins Pipeline jobs whenever an image stream tag is updated.  A **Deployment Config** allows you to use custom deployment logic to rollout your application, and Kubernetes workflow objects like **DaemonSets**, **Deployments**, or **StatefulSets** are upgraded to automatically trigger when new images are available.  **Routes** make it trivial to expose your Kubernetes services via a public DNS name. As an administrator, you can enable your developers to request new **Projects** which come with predefined roles, quotas, and security controls to fairly divide access.
+OKD builds a developer-centric workflow around containers and Kubernetes runtime concepts.  An **Image Stream** lets you easily tag, import, and publish Docker images from the integrated registry.  A **Build Config** allows you to launch Docker builds, build directly from source code, or trigger Jenkins Pipeline jobs whenever an image stream tag is updated.  A **Deployment Config** allows you to use custom deployment logic to rollout your application, and Kubernetes workflow objects like **DaemonSets**, **Deployments**, or **StatefulSets** are upgraded to automatically trigger when new images are available.  **Routes** make it trivial to expose your Kubernetes services via a public DNS name. As an administrator, you can enable your developers to request new **Projects** which come with predefined roles, quotas, and security controls to fairly divide access.
 
 For more on the underlying concepts of OKD, please see the [documentation site](https://docs.okd.io/latest/welcome/index.html).
 
@@ -103,7 +103,7 @@ OKD runs with the following security policy by default:
     * By default, Docker builds can (and often do) run as root. You can control who can create Docker builds through the `builds/docker` and `builds/custom` policy resource.
   * Regular users and project admins cannot change their security quotas.
 
-Many Docker containers expect to run as root (and therefore edit all the contents of the filesystem). The [Image Author's guide](https://docs.okd.io/latest/creating_images/guidelines.html#openshift-specific-guidelines) gives recommendations on making your image more secure by default:
+Many containers expect to run as root (and therefore edit all the contents of the filesystem). The [Image Author's guide](https://docs.okd.io/latest/creating_images/guidelines.html#openshift-specific-guidelines) gives recommendations on making your image more secure by default:
 
     * Don't run as root
     * Make directories you want to write to group-writable and owned by group id 0

Vagrantfile

@@ -205,14 +205,14 @@ Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
               rsync__args: %w(--verbose --archive --delete),
               rsync__exclude: dest["exclude"],
               type: vagrant_openshift_config['sync_folders_type'],
-              nfs_udp: false # has issues when using NFS from within a docker container
+              nfs_udp: false # has issues when using NFS from within a container
           end
         else
           config.vm.synced_folder sync_from, sync_to,
             rsync__args: %w(--verbose --archive --delete),
             rsync__exclude: vagrant_openshift_config["sync_folders_rsync_exclude"],
             type: vagrant_openshift_config['sync_folders_type'],
-            nfs_udp: false # has issues when using NFS from within a docker container
+            nfs_udp: false # has issues when using NFS from within a container
         end
       end
 

docs/builds.md

@@ -2,7 +2,7 @@
 
 ## Problem/Rationale
 
-Kubernetes creates Docker containers from images that were built elsewhere and pushed to a Docker registry. Building Docker images is a foundational use-case in Docker-based workflows for application development and deployment. Without support for builds in Kubernetes, if a system administrator wanted a system that could build images, he or she would have to select a pre-existing build system or write a new one, and then figure out how to deploy and maintain it on or off Kubernetes. However, in most cases operators would wish to leverage the ability of Kubernetes to schedule task execution into a pool of available resources, and most build systems would want to take advantage of that mechanism.
+Kubernetes creates containers from images that were built elsewhere and pushed to a Docker registry. Building Docker images is a foundational use-case in Docker-based workflows for application development and deployment. Without support for builds in Kubernetes, if a system administrator wanted a system that could build images, he or she would have to select a pre-existing build system or write a new one, and then figure out how to deploy and maintain it on or off Kubernetes. However, in most cases operators would wish to leverage the ability of Kubernetes to schedule task execution into a pool of available resources, and most build systems would want to take advantage of that mechanism.
 
 Offering an API for builds makes OpenShift a viable back-end for arbitrary third-party Docker image build systems which require resource constraints and scheduling capabilities, and allows organizations to orchestrate Docker builds from their existing continuous integration processes. OpenShift enables CI/CD flows around Docker images.
 
@@ -57,7 +57,7 @@ There are viable paths to alleviate or resolve each of these disadvantages, and
 
 ##### Why not Docker-in-Docker?
 
-It's theoretically possible to implement builds using a nested Docker daemon within a Docker container (Docker-in-Docker). On the surface, this approach offers some compelling advantages:
+It's theoretically possible to implement builds using a nested Docker daemon within a container (Docker-in-Docker). On the surface, this approach offers some compelling advantages:
 
 1.  Build process resources can be naturally constrained to the user’s acceptable limits (cgroups)
 2.  Containers created during the build have the build container as their parent process, making container cleanup simple

docs/debugging-openshift.md

@@ -47,7 +47,7 @@ and you can get the build id via:
 
 the build id is in the first column.
 
-If you're unable to retrieve the logs in this way, you can also get them directly from docker.  First you need to find the docker container that ran your build:
+If you're unable to retrieve the logs in this way, you can also get them directly from docker.  First you need to find the container that ran your build:
 
     $ docker ps -a | grep builder
 
@@ -119,7 +119,7 @@ Obviously this won't work if you don't have bash installed but you could always
 Name Resolution Within Containers
 -------------------
 
-DNS related services like `dnsmasq` can interfere with naming resolution in the Docker containers launched by OpenShift, including binding on the same port (53) that OpenShift will attempt to use.  To circumvent this conflict, disable
+DNS related services like `dnsmasq` can interfere with naming resolution in the containers launched by OpenShift, including binding on the same port (53) that OpenShift will attempt to use.  To circumvent this conflict, disable
 these services.  Using the `dnsmasq` example on Fedora, run all three of the following before starting OpenShift to ensure `dnsmasq` is not running, does not launch later on, and hence does not interfere with OpenShift:
 
     $ sudo systemctl stop dnsmasq

docs/images.md

@@ -1,6 +1,6 @@
 # OpenShift Images
 ## Problem/Rationale
-Kubernetes creates Docker containers from images stored in Docker registries. It does not currently track and store any information about images; it merely pulls and stores them locally on a minion as part of the pod creation process.
+Kubernetes creates containers from images stored in Docker registries. It does not currently track and store any information about images; it merely pulls and stores them locally on a minion as part of the pod creation process.
 
 Adding information related to images - image repositories, the images themselves, tags, and metadata - as resources in an image component will provide foundational support for several use cases, listed below.
 

examples/sample-app/README.md

@@ -9,13 +9,13 @@ equivalent for your host platform/architecture), you have that and its
 symlink/copy `oc` in your `PATH` and root's, and Docker is installed and
 working. See https://github.com/openshift/origin/blob/master/CONTRIBUTING.adoc.
 
-Alternatively, if you are using the openshift/origin Docker container, please
+Alternatively, if you are using the openshift/origin container, please
 make sure you follow these instructions first:
 https://github.com/openshift/origin/blob/master/examples/sample-app/container-setup.md
 
 Security Warning
 ----------------
-OpenShift no longer requires SElinux to be disabled, however OpenShift is a system which runs Docker containers on your system.  In some cases (build operations and the registry service) it does so using privileged containers.  Furthermore those containers access your host's Docker daemon and perform `docker build` and `docker push` operations.  As such, you should be aware of the inherent security risks associated with performing `docker run` operations on arbitrary images as they effectively have root access.  This is particularly relevant when running the OpenShift nodes directly on your host system.
+OpenShift no longer requires SElinux to be disabled, however OpenShift is a system which runs containers on your system.  In some cases (build operations and the registry service) it does so using privileged containers.  Furthermore those containers access your host's Docker daemon and perform `docker build` and `docker push` operations.  As such, you should be aware of the inherent security risks associated with performing `docker run` operations on arbitrary images as they effectively have root access.  This is particularly relevant when running the OpenShift nodes directly on your host system.
 
 For more information, see these articles:
 
@@ -415,7 +415,7 @@ Another interesting example is deleting a pod.
 
         $ oc delete pod frontend-1-votq4
 
-  - Verify that the pod has been removed by listing the available pods. This also stopped the associated Docker container, you can check using the command:
+  - Verify that the pod has been removed by listing the available pods. This also stopped the associated container, you can check using the command:
 
         $ docker ps -a
         CONTAINER ID        IMAGE                                                COMMAND                CREATED              STATUS                          PORTS               NAMES
@@ -430,6 +430,6 @@ To clean up all of your environment, you can run the script:
 
         $ sudo ./cleanup.sh
 
-This will stop the `openshift` process, remove files created by OpenShift and kill all Docker containers created by Kubernetes in your host system.  The cleanup script needs root privileges to be able to remove all the directories OpenShift created.
+This will stop the `openshift` process, remove files created by OpenShift and kill all containers created by Kubernetes in your host system.  The cleanup script needs root privileges to be able to remove all the directories OpenShift created.
 
-**Use with caution!** Any Docker container prefixed with "k8s_" will be killed by this script.
+**Use with caution!** Any container prefixed with "k8s_" will be killed by this script.

examples/sample-app/cleanup.sh

@@ -3,7 +3,7 @@
 echo "Killing openshift all-in-one server ..."
 sudo pkill -x openshift
 
-echo "Stopping all k8s docker containers on host ..."
+echo "Stopping all k8s containers on host ..."
 sudo docker ps --format='{{.Names}}' | grep -E '^k8s_' | xargs -l -r sudo docker stop
 
 echo "Unmounting openshift local volumes ..."

examples/sample-app/container-setup.md

@@ -5,7 +5,7 @@ things to get it going.
 
 ## Download and Run OpenShift Origin
 If you have not already, perform the following to (download and) run the Origin
-Docker container:
+container:
 
     $ docker run -d --name "openshift-origin" --net=host --privileged \
     -v /var/run/docker.sock:/var/run/docker.sock \
@@ -46,7 +46,7 @@ you know where you are:
     $ PS1="openshift-dock: [\u@\h \W]\$ "
 
 ## Get the Sample Application Code
-Inside the OpenShift Docker container, you'll need to fetch some of the code
+Inside the OpenShift container, you'll need to fetch some of the code
 bits that are used in the sample app.
 
     $ cd /var/lib/openshift

examples/storage-examples/gluster-examples/nginx_gluster_host/README.md

@@ -171,7 +171,7 @@ _Under volumes_
 *Notice we also see our `helloworld.html` file that we created within that directory*
 
 
-- Enter a simple curl command from the docker container to serve the page
+- Enter a simple curl command from the container to serve the page
 
 
         curl http://10.1.0.9/test/helloworld.html

examples/storage-examples/gluster-examples/nginx_gluster_plugin/README.md

@@ -235,7 +235,7 @@ _Under volumes_
 
 
 
-- Enter simple curl command from the docker container to serve the page
+- Enter simple curl command from the container to serve the page
 
 
         curl http://10.1.0.10/test/glusterfs-nginx/helloworld.html

examples/storage-examples/gluster-examples/nginx_gluster_pvc/README.md

@@ -268,7 +268,7 @@ At this point, all [environment assumptions](../../gluster-examples) are met, an
 *Notice we also see our helloworld.html file that we created within that directory*
 
 
-- Enter simple curl command from the docker container to serve the page
+- Enter simple curl command from the container to serve the page
 
         curl http://10.1.0.12/test/glusterfs-nginx-pvc/helloworld.html
 

examples/storage-examples/gluster-examples/nginx_template/README.md

@@ -178,7 +178,7 @@ _Also, take note that for this simple example, we are simply creating a pod that
 *Notice we also see our helloworld.html file that we created within that directory*
 
 
-- Enter simple curl command from the docker container to serve the page
+- Enter simple curl command from the container to serve the page
 
         curl http://10.1.0.12/test/gluster-nginx-pvc-template/helloworld.html
 

examples/storage-examples/host-path-examples/README.md

@@ -110,7 +110,7 @@ _Under volumes_
         hello.html  *helloworld.html*
 
 
-- Enter simple curl command from the docker container to serve the page
+- Enter simple curl command from the container to serve the page
 
         curl http://10.1.0.2/test/helloworld.html
 

hack/dind-cluster.sh

@@ -1069,11 +1069,11 @@ case "${1:-""}" in
 
 Commands:
 - start: Starts the containers in an openshift docker-in-docker environment
-- stop: Destroys the docker containers for the docker-in-docker environment
+- stop: Destroys the containers for the docker-in-docker environment
 - add-node: Adds a node to the cluster
 - delete-node <node-num>: Deletes the given node from the cluster
 - refresh: Refreshes the openshift binaries in the containers and reloads the processes
-- ps: List all of the docker containers that make up the cluster
+- ps: List all of the containers that make up the cluster
 - pause: Stops running containers, but leaves the state around
 - resume: Restarts paused containers
 - copy-image: Copies an image from the outer docker into all node dockers

hack/env

@@ -1,6 +1,6 @@
 #!/bin/bash
 
-# This starts a Docker container using the release image (openshift/origin-release:golang-1.8)
+# This starts a container using the release image (openshift/origin-release:golang-1.8)
 # and syncs the local directory into that image. The default mode performs a 'git archive' of
 # the current HEAD, so you get a reproducible environment. You can also set
 # OS_BUILD_ENV_REUSE_VOLUME to a docker volume name to rsync (or docker cp) the contents of
@@ -39,4 +39,4 @@ relative_script_path="$( os::util::repository_relative_path "${OS_OUTPUT_SCRIPTP
 default_preserve_paths="${relative_bin_path}:${relative_release_path}:${relative_script_path}"
 export OS_BUILD_ENV_PRESERVE="${OS_BUILD_ENV_PRESERVE:-"${default_preserve_paths}"}"
 
-os::build::environment::run "$@"
+os::build::environment::run "$@"

hack/lib/cleanup.sh

@@ -120,7 +120,7 @@ function os::cleanup::containers() {
 		return
 	fi
 
-	os::log::info "[CLEANUP] Stopping docker containers"
+	os::log::info "[CLEANUP] Stopping containers"
 	for id in $( os::cleanup::internal::list_our_containers ); do
 		os::log::debug "Stopping ${id}"
 		docker stop "${id}" >/dev/null
@@ -130,7 +130,7 @@ function os::cleanup::containers() {
 		return
 	fi
 
-	os::log::info "[CLEANUP] Removing docker containers"
+	os::log::info "[CLEANUP] Removing containers"
 	for id in $( os::cleanup::internal::list_our_containers ); do
 		os::log::debug "Removing ${id}"
 		docker rm --volumes "${id}" >/dev/null
@@ -166,7 +166,7 @@ function os::cleanup::dump_container_logs() {
 readonly -f os::cleanup::dump_container_logs
 
 # os::cleanup::internal::list_our_containers returns a space-delimited list of
-# docker containers that belonged to some part of the Origin deployment.
+# containers that belonged to some part of the Origin deployment.
 #
 # Globals:
 #  None
@@ -181,7 +181,7 @@ function os::cleanup::internal::list_our_containers() {
 readonly -f os::cleanup::internal::list_our_containers
 
 # os::cleanup::internal::list_k8s_containers returns a space-delimited list of
-# docker containers that belonged to k8s.
+# containers that belonged to k8s.
 #
 # Globals:
 #  None
@@ -195,7 +195,7 @@ function os::cleanup::internal::list_k8s_containers() {
 readonly -f os::cleanup::internal::list_k8s_containers
 
 # os::cleanup::internal::list_containers returns a space-delimited list of
-# docker containers that match a name regex.
+# containers that match a name regex.
 #
 # Globals:
 #  None

pkg/build/apis/build/types.go

@@ -720,7 +720,7 @@ type CustomBuildStrategy struct {
 	Env []kapi.EnvVar
 
 	// ExposeDockerSocket will allow running Docker commands (and build Docker images) from
-	// inside the Docker container.
+	// inside the container.
 	// TODO: Allow admins to enforce 'false' for this option
 	ExposeDockerSocket bool
 

staging/src/github.com/openshift/oc/pkg/cli/deployer/strategy/doc.go

@@ -1,5 +1,5 @@
 // Package strategy contains implementations of core deployment strategies.
 //
 // The code in this package will be more verbose with logging given the intended application as
-// standalone Docker container CLI support.
+// standalone container CLI support.
 package strategy

staging/src/github.com/openshift/oc/pkg/cli/rollout/rollout.go

@@ -27,7 +27,7 @@ var (
 		* Recreate - scales the old replication controller down to zero, then scales the new replication
 			controller up to full. Use when your application cannot tolerate two versions of code running
 			at the same time
-		* Custom - run your own deployment process inside a Docker container using your own scripts.`)
+		* Custom - run your own deployment process inside a container using your own scripts.`)
 )
 
 // NewCmdRollout facilitates kubectl rollout subcommands

test/extended/testdata/bindata.go

@@ -285,7 +285,7 @@ type NodeAuthConfig struct {
 // DockerConfig holds Docker related configuration options.
 type DockerConfig struct {
 	// ExecHandlerName is the name of the handler to use for executing
-	// commands in Docker containers.
+	// commands in containers.
 	ExecHandlerName DockerExecHandlerType
 	// DockerShimSocket is the location of the dockershim socket the kubelet uses.
 	DockerShimSocket string