Change references from Docker registry to container image registry.

Trying to remove as many references to Docker as possible.

Signed-off-by: Daniel J Walsh <[email protected]>

Author: rhatdan

HACKING.md

@@ -8,7 +8,7 @@ system with Docker, which will create a build environment image and then
 execute a cross-platform Go build within it. The build output will be copied
 to `_output/releases` as a set of tars containing each version. It will also
 build the `openshift/origin-base` image which is the common parent image for all
-OpenShift Docker images.
+OpenShift container images.
 
     $ make release
 

README.md

@@ -26,7 +26,7 @@ OKD: The Origin Community Distribution of Kubernetes
 * Multi-tenancy support, including team and user isolation of containers, builds, and network communication.
   * Allow developers to run containers securely with fine-grained controls in production.
   * Limit, track, and manage the developers and teams on the platform.
-* Integrated Docker registry, automatic edge load balancing, cluster logging, and integrated metrics.
+* Integrated container image registry, automatic edge load balancing, cluster logging, and integrated metrics.
 
 **Learn More:**
 
@@ -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 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 container 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).
 
@@ -71,9 +71,9 @@ If you're looking for more information about using Kubernetes or the lower level
 
 ### What can I run on OKD?
 
-OKD is designed to run any existing Docker images.  Additionally, you can define builds that will produce new Docker images using a `Dockerfile`.
+OKD is designed to run any existing container images.  Additionally, you can define builds that will produce new container images using a `Dockerfile`.
 
-For an easier experience running your source code, [Source-to-Image (S2I)](https://github.com/openshift/source-to-image) allows developers to simply provide an application source repository containing code to build and run.  It works by combining an existing S2I-enabled Docker image with application source to produce a new runnable image for your application.
+For an easier experience running your source code, [Source-to-Image (S2I)](https://github.com/openshift/source-to-image) allows developers to simply provide an application source repository containing code to build and run.  It works by combining an existing S2I-enabled container image with application source to produce a new runnable image for your application.
 
 You can see the [full list of Source-to-Image builder images](https://docs.okd.io/latest/using_images/s2i_images/overview.html) and it's straightforward to [create your own](https://blog.openshift.com/create-s2i-builder-image/).  Some of our available images include:
 
@@ -206,7 +206,7 @@ You'll need [etcd](https://github.com/coreos/etcd) installed and on your path fo
 $ hack/install-etcd.sh
 ```
 
-Some of the components of Origin run as Docker images, including the builders and deployment tools in `images/builder/docker/*` and `images/deploy/*`.  To build them locally run
+Some of the components of Origin run as container images, including the builders and deployment tools in `images/builder/docker/*` and `images/deploy/*`.  To build them locally run
 
 ```
 $ hack/build-images.sh

UPGRADE.md

@@ -23,7 +23,7 @@ when that change will happen.
 1. The `/ns/namespace-name/subjectaccessreview` endpoint is deprecated, use `/subjectaccessreview`
 (with the `namespace` field set) or `/ns/namespace-name/localsubjectaccessreview`.  In
 Origin 1.y / OSE 3.y, support for `/ns/namespace-name/subjectaccessreview` will be removed.
-At that time, the openshift docker registry image must be upgraded in order to continue functioning.
+At that time, the openshift container image registry image must be upgraded in order to continue functioning.
 
 1. The `deploymentConfig.spec.strategy.rollingParams.updatePercent` field is deprecated in
   favor of `deploymentConfig.spec.strategy.rollingParams.maxUnavailable` and
@@ -88,8 +88,8 @@ references:
   Incorrectly cased field names will now be rejected.  Please ensure all `yaml` and `json` files
   conform to the naming conventions defined in [REST API](https://docs.okd.io/latest/rest_api/index.html) 
 
-1.  The existing docker registry images will not be able to support auto-provisioning of image streams based on docker pushes against new API servers.
-  Upgrade your docker registry image to make auto-provisioning work again.
+1.  The existing container image registry images will not be able to support auto-provisioning of image streams based on docker pushes against new API servers.
+  Upgrade your container image registry image to make auto-provisioning work again.
 1. New service accounts specific to the PersistentVolume operations of binding, recycling, and provisioning were added.  Run `oc adm policy reconcile-sccs --confirm` to update your SecurityContextConstraints.
 
 ## Origin 1.3.x / OSE 3.3.x

contrib/migration/migrate-image-manifests.sh

@@ -246,7 +246,7 @@ if [[ -z "${token:-}" ]]; then
 fi
 
 if ! curl --fail ${curlargs[@]-} --max-time 15 "${url}/healthz"; then
-    echo "Please, provide endpoint of integrated docker registry." >&2
+    echo "Please, provide endpoint of integrated container image registry." >&2
     exit 1
 fi
 

doc.go

@@ -1,4 +1,4 @@
 // This is the source repository for OpenShift Origin - the best way to build, manage, and deploy
-// applications in the cloud.  The OpenShift 3.0 codebase is based around Docker images and containers
+// applications in the cloud.  The OpenShift 3.0 codebase is based around container images and containers
 // and the Kubernetes container management system.
 package origin

docs/builds.md

@@ -2,30 +2,30 @@
 
 ## Problem/Rationale
 
-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.
+Kubernetes creates containers from images that were built elsewhere and pushed to a container image registry. Building container 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.
+Offering an API for builds makes OpenShift a viable back-end for arbitrary third-party container 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 container images.
 
 Most build jobs share common characteristics - a set of inputs to a build, the need to run a certain build process to completion, the capture of the logs from that build process, publishing resources from successful builds, and the final status of the build. In addition, the image-driven deployment flow that Kubernetes advocates depends on having images available.
 
 Builds should take advantage of resource restrictions – specifying limitations on things such as CPU usage, memory usage, and build (pod) execution time – once support for this exists in Kubernetes. Additionally, builds should be repeatable and consistent (same inputs = same output).
 
-Although there are potentially several different types of builds that produce other types of output, OpenShift by default provides the ability to build Docker images.
+Although there are potentially several different types of builds that produce other types of output, OpenShift by default provides the ability to build container images.
 
 Here are some possible user scenarios for builds in OpenShift:
 
 1.   As a user of OpenShift, I want to build an image from a source URL and push it to a registry (for eventual deployment in OpenShift).
 2.   As a user of OpenShift, I want to build an image from a binary input (Docker context, artifact) and push it to a registry (for eventual deployment in OpenShift).
-3.   As a provider of a service that involves building Docker images, I want to offload the resource allocation, scheduling, and garbage collection associated with that activity to OpenShift instead of solving those problems myself.
-4.   As a developer of a system which involves building Docker images, I want to take advantage of OpenShift to perform the build, but orchestrate from an existing CI in order to integrate with my organization’s devops SOPs.
+3.   As a provider of a service that involves building container images, I want to offload the resource allocation, scheduling, and garbage collection associated with that activity to OpenShift instead of solving those problems myself.
+4.   As a developer of a system which involves building container images, I want to take advantage of OpenShift to perform the build, but orchestrate from an existing CI in order to integrate with my organization’s devops SOPs.
 
 ### Example Use: Cloud IDE
 
-Company X offers a Docker-based cloud IDE service and needs to build Docker images at scale for their customers’ hosted projects. Company X wants a turn-key solution for this that handles scheduling, resource allocation, and garbage collection. Using the build API, Company X can leverage OpenShift for the build work and concentrate on solving their core business problems.
+Company X offers a Docker-based cloud IDE service and needs to build container images at scale for their customers’ hosted projects. Company X wants a turn-key solution for this that handles scheduling, resource allocation, and garbage collection. Using the build API, Company X can leverage OpenShift for the build work and concentrate on solving their core business problems.
 
 ### Example Use: Enterprise Devops
 
-Company Y wants to leverage OpenShift to build Docker images, but their Devops SOPs mandate the use of a third-party CI server in order to facilitate actions such as triggering builds when an upstream project is built and promoting builds when the result is signed off on in the CI server. Using the build API, company Y implements workflows in the CI server that orchestrate building in OpenShift which integrates with their organization’s SOPs.
+Company Y wants to leverage OpenShift to build container images, but their Devops SOPs mandate the use of a third-party CI server in order to facilitate actions such as triggering builds when an upstream project is built and promoting builds when the result is signed off on in the CI server. Using the build API, company Y implements workflows in the CI server that orchestrate building in OpenShift which integrates with their organization’s SOPs.
 
 ## Build Strategies
 
@@ -76,7 +76,7 @@ For these reasons, Docker-in-Docker is not considered a viable build strategy fo
 
 OpenShift also supports [Source-To-Images (s2i)](https://github.com/openshift/source-to-image#source-to-image-sti) builds.
 
-Source-to-images (s2i) is a tool for building reproducible Docker images. It produces ready-to-run images by injecting a user source into a docker image and assembling a new Docker image which incorporates the base image and built source, and is ready to use with `docker run`. S2I supports incremental builds which re-use previously downloaded dependencies, previously built artifacts, etc.
+Source-to-images (s2i) is a tool for building reproducible container images. It produces ready-to-run images by injecting a user source into a container image and assembling a new container image which incorporates the base image and built source, and is ready to use with `docker run`. S2I supports incremental builds which re-use previously downloaded dependencies, previously built artifacts, etc.
 
 ### Custom Builds
 
@@ -107,8 +107,8 @@ be passed to the builder container environment. By default, these environment
 variables are passed to the build container:
 
 * `$BUILD` contains the JSON representation of the Build
-* `$OUTPUT_IMAGE` contains the output Docker image name as configured in Build
-* `$OUTPUT_REGISTRY` contains the output Docker registry as configured in Build
+* `$OUTPUT_IMAGE` contains the output container image name as configured in Build
+* `$OUTPUT_REGISTRY` contains the output container image registry as configured in Build
 * `$SOURCE_URI` contains the URL to the source code repository
 * `$SOURCE_REF` contains the branch, tag or ref for source repository
 * `$DOCKER_SOCKET` contains full path to the Docker socket

docs/cli.md

@@ -82,7 +82,7 @@ Note that we use double-quotes around the option arguments.
 
 This creates a new application in OpenShift with the specified source code, templates, and images.
 It builds up the components of an application using images, templates, or code that has a public repository.
-It looks up images on the local Docker installation (if available), a Docker registry, or an OpenShift image stream.
+It looks up images on the local Docker installation (if available), a container image registry, or an OpenShift image stream.
 If you specify a source code URL, it sets up a build that takes the source code and converts it into an image that can run in a pod.
 Local source must be in a git repository that has a remote repository that the OpenShift instance can see.
 The images will be deployed via a deployment configuration, and a service will be connected to the first public port of the app.
@@ -103,12 +103,12 @@ The options are:
 |:-----------------------------|:---------------------------------------------------|
 |`--code` *dir*                | Use source code in *dir*                           |
 |`--context-dir` *dir*         | Use *dir* as context dir in the build              |
-|`--docker-image` *image*      | Include Docker image *image* in the app            |
+|`--docker-image` *image*      | Include container image *image* in the app            |
 |`--env` (`-e`) *k=v*          | Set env var *k* to value *v*                       |
 |`--file` *filename*           | Use template in *filename*                         |
 |`--group` *comp1*`+`*comp2*   | Group together components *comp1* and *comp2*      |
 |`--image-stream` (`-i`) *is*  | Use imagestream *is* in the app                    |
-|`--insecure-registry`         | Bypass cert checks for referenced Docker images    |
+|`--insecure-registry`         | Bypass cert checks for referenced container images    |
 |`--labels` (`-l`) *k1=v1,...* | Label all resources with *k1=v1,...*               |
 |`--name` *name*               | Give *name* to all generated app artifacts         |
 |`--no-headers`                | For default output, don't print headers            |
@@ -235,7 +235,7 @@ See also [`oc replace`](#oc-replace).
 
 This creates a new build with the specified source code.
 It creates a build configuration for your application using images and code that has a public repository.
-It looks up the images on the local Docker installation (if available), a Docker registry, or an OpenShift image stream.
+It looks up the images on the local Docker installation (if available), a container image registry, or an OpenShift image stream.
 If you specify a source code URL, it sets up a build that takes the source code and converts it into an image that can run inside a pod.
 Local source must be in a git repository that has a remote repository that the OpenShift instance can see.
 
@@ -302,7 +302,7 @@ See also [`oc new-build`](#oc-new-build).
 
 ### oc import-image
 
-This imports tag and image information from an external Docker image registry.
+This imports tag and image information from an external container image registry.
 For example, the following command imports from the `mystream` registry.
 
 ```bash

docs/debugging-openshift.md

@@ -55,7 +55,7 @@ The most recent container in that list should be the one that ran your build.  T
 
     $ docker logs [container id]
 
-Hopefully the logs will provide some indication of what it failed (e.g. failure to find the source repository, an actual build issue, failure to push the resulting image to the docker registry, etc).
+Hopefully the logs will provide some indication of what it failed (e.g. failure to find the source repository, an actual build issue, failure to push the resulting image to the container image registry, etc).
 
 One issue seen sometimes is not being able to resolve any hostname (for example github.com) from within running containers:
 
@@ -69,13 +69,13 @@ If this shows up in your build logs, restart docker and then resubmit a build:
 Docker Registry
 ---------------
 
-Most of the v3 flows today assume you are running a docker registry pod.  You should ensure that this local registry is running:
+Most of the v3 flows today assume you are running a container image registry pod.  You should ensure that this local registry is running:
 
     $ oc adm registry --dry-run
 
 If it's running, you should see this:
 
-    Docker registry "docker-registry" service exists
+    container image registry "docker-registry" service exists
 
 If it's not running, you will instead see: