openshift · bmcelvee · Aug 14, 2018 · Aug 9, 2018
diff --git a/admin_guide/high_availability.adoc b/admin_guide/high_availability.adoc
@@ -369,7 +369,7 @@ decimal) is typical.
 ----
 $ oc set env dc/ipf-ha-router \
     OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh
-$ oc volume dc/ipf-ha-router --add --overwrite \
+$ oc set volume dc/ipf-ha-router --add --overwrite \
     --name=config-volume \
     --mount-path=/etc/keepalive \
     --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'
@@ -595,12 +595,12 @@ IP failover management is limited to 254 groups of VIP addresses. By default
 [product-title] assigns one IP address to each group. You can use the
 `virtual-ip-groups` option to change this so multiple IP addresses are in each
 group and define the number of VIP groups available for each VRRP instance when
-xref:configuring-ip-failover[configuring IP failover]. 
+xref:configuring-ip-failover[configuring IP failover].
 
 Grouping VIPs creates a wider range of allocation of VIPs per VRRP in the case
 of VRRP failover events, and is useful when all hosts in the cluster have access
 to a service locally. For example, when a service is being exposed with an
-`ExternalIP`. 
+`ExternalIP`.
 
 [NOTE]
 ====

diff --git a/admin_guide/managing_networking.adoc b/admin_guide/managing_networking.adoc
@@ -201,7 +201,7 @@ name of `router` for the deployment configuration and the service-account):
 . Set the `ROUTER_ENABLE_INGRESS` environment variable to `true`:
 +
 ----
-$ oc env dc router ROUTER_ENABLE_INGRESS=true`
+$ oc set env dc router ROUTER_ENABLE_INGRESS=true`
 ----
 
 . Add the `cluster-reader` role to the router, where `-z` is the service

diff --git a/admin_guide/pruning_resources.adoc b/admin_guide/pruning_resources.adoc
@@ -609,7 +609,7 @@ To switch the registry to read-only mode:
 .. Set the following envirornment variable:
 +
 ----
-$ oc env -n default \
+$ oc set env -n default \
     dc/docker-registry \
     'REGISTRY_STORAGE_MAINTENANCE_READONLY={"enabled":true}'
 ----
@@ -706,7 +706,7 @@ Freed up 2.835 GiB of disk space
 finished, the registry can be switched back to read-write mode by executing:
 +
 ----
-$ oc env -n default dc/docker-registry REGISTRY_STORAGE_MAINTENANCE_READONLY-
+$ oc set env -n default dc/docker-registry REGISTRY_STORAGE_MAINTENANCE_READONLY-
 ----
 endif::[]
 

diff --git a/architecture/networking/routes.adoc b/architecture/networking/routes.adoc
@@ -805,7 +805,7 @@ To implement both scenarios, run:
 
 ----
 $ oc adm router adrouter ...
-$ oc env dc/adrouter ROUTER_ALLOWED_DOMAINS="okd.io, kates.net" \
+$ oc set env dc/adrouter ROUTER_ALLOWED_DOMAINS="okd.io, kates.net" \
     ROUTER_DENIED_DOMAINS="ops.openshift.org, metrics.kates.net"
 ----
 
@@ -960,6 +960,6 @@ $ oc adm router ... --disable-namespace-ownership-check=true
 ----
 
 ----
-$ oc env dc/router ROUTER_DISABLE_NAMESPACE_OWNERSHIP_CHECK=true
+$ oc set env dc/router ROUTER_DISABLE_NAMESPACE_OWNERSHIP_CHECK=true
 ----
 endif::openshift-origin,openshift-enterprise[]
diff --git a/cli_reference/basic_cli_operations.adoc b/cli_reference/basic_cli_operations.adoc
@@ -235,7 +235,7 @@ $ oc edit <object_type>/<object_name> \
 === volume
 Modify a xref:../dev_guide/volumes.adoc#dev-guide-volumes[volume]:
 ----
-$ oc volume <object_type>/<object_name> [--option]
+$ oc set volume <object_type>/<object_name> [--option]
 ----
 
 [[oc-label]]
@@ -655,22 +655,22 @@ $ oc debug -h
 ----
 
 When debugging images and setup problems, you can get an exact copy of a
-running pod configuration and troubleshoot with a shell. Since a failing pod 
+running pod configuration and troubleshoot with a shell. Since a failing pod
 may not be started and not accessible to `rsh` or `exec`, running the `debug`
-command creates a carbon copy of that setup. 
+command creates a carbon copy of that setup.
 
 The default mode is to start a shell inside of the first container of the
 referenced pod, replication controller, or deployment configuration. The started pod
 will be a copy of your source pod, with labels stripped, the command changed to
 `/bin/sh`, and readiness and liveness checks disabled. If you just want to run a
 command, add `--` and a command to run. Passing a command will not create a TTY
 or send STDIN by default. Other flags are supported for altering the container
-or pod in common ways. 
+or pod in common ways.
 
 A common problem running containers is a security policy that prohibits you from
 running as a root user on the cluster. You can use this command to test running
 a pod as non-root (with `--as-user`) or to run a non-root pod as root (with
-`--as-root`). 
+`--as-root`).
 
 The debug pod is deleted when the remote command completes or you interrupt
 the shell.

diff --git a/cli_reference/cli_by_example_content.adoc b/cli_reference/cli_by_example_content.adoc
@@ -387,40 +387,40 @@
 ----
   // Add new volume of type 'emptyDir' for deployment config 'registry' and mount under /opt inside the containers
   // The volume name is auto generated
-  $ oc volume dc/registry --add --mount-path=/opt
+  $ oc set volume dc/registry --add --mount-path=/opt
 
   // Add new volume 'v1' with secret 'magic' for pod 'p1'
-  $ oc volume pod/p1 --add --name=v1 -m /etc --type=secret --secret-name=magic
+  $ oc set volume pod/p1 --add --name=v1 -m /etc --type=secret --secret-name=magic
 
   // Add new volume to pod 'p1' based on gitRepo (or other volume sources not supported by --type)
-  $ oc volume pod/p1 --add -m /repo --source=<json-string>
+  $ oc set volume pod/p1 --add -m /repo --source=<json-string>
 
   // Add emptyDir volume 'v1' to a pod definition on disk and update the pod on the server
-  $ oc volume -f pod.json --add --name=v1
+  $ oc set volume -f pod.json --add --name=v1
 
   // Create a new persistent volume and overwrite existing volume 'v1' for replication controller 'r1'
-  $ oc volume rc/r1 --add --name=v1 -t persistentVolumeClaim --claim-name=pvc1 --overwrite
+  $ oc set volume rc/r1 --add --name=v1 -t persistentVolumeClaim --claim-name=pvc1 --overwrite
 
   // Change pod 'p1' mount point to /data for volume v1
-  $ oc volume pod p1 --add --name=v1 -m /data --overwrite
+  $ oc set volume pod p1 --add --name=v1 -m /data --overwrite
 
   // Remove all volumes for pod 'p1'
-  $ oc volume pod/p1 --remove --confirm
+  $ oc set volume pod/p1 --remove --confirm
 
   // Remove volume 'v1' from deployment config 'registry'
-  $ oc volume dc/registry --remove --name=v1
+  $ oc set volume dc/registry --remove --name=v1
 
   // Unmount volume v1 from container c1 on pod p1 and remove the volume v1 if it is not referenced by any containers on pod p1
-  $ oc volume pod/p1 --remove --name=v1 --containers=c1
+  $ oc set volume pod/p1 --remove --name=v1 --containers=c1
 
   // List volumes defined on replication controller 'r1'
-  $ oc volume rc r1 --list
+  $ oc set volume rc r1 --list
 
   // List volumes defined on all pods
-  $ oc volume pods --all --list
+  $ oc set volume pods --all --list
 
   // Output json object with volume info for pod 'p1' but don't alter the object on server
-  $ oc volume pod/p1 --add --name=v1 --mount=/opt -o json
+  $ oc set volume pod/p1 --add --name=v1 --mount=/opt -o json
 ----
 ====
 

diff --git a/day_two_guide/topics/proc_restoring-data-new-pvc.adoc b/day_two_guide/topics/proc_restoring-data-new-pvc.adoc
@@ -18,7 +18,7 @@ The following steps assume that a new `pvc` has been created.
 . Overwrite the currently defined `claim-name`:
 +
 ----
-$ oc volume dc/demo --add --name=persistent-volume \
+$ oc set volume dc/demo --add --name=persistent-volume \
 		--type=persistentVolumeClaim --claim-name=filestore \ --mount-path=/opt/app-root/src/uploaded --overwrite
 ----
 

diff --git a/day_two_guide/topics/pvc_backup_and_restore.adoc b/day_two_guide/topics/pvc_backup_and_restore.adoc
@@ -16,7 +16,7 @@ claim.
 Depending on the provider that is hosting the {product-title} environment, the
 ability to launch third party snapshot services for backup and restore purposes
 also exists. As {product-title} does not have the ability to launch these
-services, this guide does not describe these steps. 
+services, this guide does not describe these steps.
 ====
 
 Consult any product documentation for the correct backup procedures of specific
@@ -73,7 +73,7 @@ Containers:
 ----
 +
 The above shows that the persistent data is currently located in the
-`/opt/app-root/src/uploaded` directory. 
+`/opt/app-root/src/uploaded` directory.
 
 . Copy the data locally:
 +
@@ -152,7 +152,7 @@ The following steps assume that a new `pvc` has been created.
 . Overwrite the currently defined `claim-name`:
 +
 ----
-$ oc volume dc/demo --add --name=persistent-volume \
+$ oc set volume dc/demo --add --name=persistent-volume \
 		--type=persistentVolumeClaim --claim-name=filestore \ --mount-path=/opt/app-root/src/uploaded --overwrite
 ----
 

diff --git a/dev_guide/dev_tutorials/maven_tutorial.adoc b/dev_guide/dev_tutorials/maven_tutorial.adoc
@@ -118,7 +118,7 @@ endif::[]
 Add a PVC to the Nexus deployment configuration.
 
 ----
-$ oc volumes dc/nexus --add \
+$ oc set volume dc/nexus --add \
 	--name 'nexus-volume-1' \
 	--type 'pvc' \
 	--mount-path '/sonatype-work/' \

diff --git a/dev_guide/volumes.adoc b/dev_guide/volumes.adoc
@@ -34,7 +34,7 @@ to your pods.
 FSGroup, if the FSGroup parameter is enabled by your cluster administrator.
 ====
 
-You can use the CLI command `oc volume` to xref:adding-volumes[add],
+You can use the CLI command `oc set volume` to xref:adding-volumes[add],
 xref:updating-volumes[update], or xref:removing-volumes[remove] volumes and
 volume mounts for any object that has a pod template like
 xref:../architecture/core_concepts/deployments.adoc#replication-controllers[replication
@@ -47,10 +47,10 @@ object that has a pod template.
 
 == General CLI Usage
 
-The `oc volume` command uses the following general syntax:
+The `oc set volume` command uses the following general syntax:
 
 ----
-$ oc volume <object_selection> <operation> <mandatory_parameters> <optional_parameters>
+$ oc set volume <object_selection> <operation> <mandatory_parameters> <optional_parameters>
 ----
 
 This topic uses the form `_<object_type>_/_<name>_` for `_<object_selection>_`
@@ -98,7 +98,7 @@ selected operation and are discussed in later sections.
 To add a volume, a volume mount, or both to pod templates:
 
 ----
-$ oc volume <object_type>/<name> --add [options]
+$ oc set volume <object_type>/<name> --add [options]
 ----
 
 [[add-options]]
@@ -165,22 +165,22 @@ values: `json`, `yaml`.
 Add a new volume source *emptyDir* to deployment configuration *registry*:
 
 ----
-$ oc volume dc/registry --add
+$ oc set volume dc/registry --add
 ----
 
 Add volume *v1* with secret *$ecret* for replication controller *r1* and mount
 inside the containers at *_/data_*:
 
 ----
-$ oc volume rc/r1 --add --name=v1 --type=secret --secret-name='$ecret' --mount-path=/data
+$ oc set volume rc/r1 --add --name=v1 --type=secret --secret-name='$ecret' --mount-path=/data
 ----
 
 Add existing persistent volume *v1* with claim name *pvc1* to deployment
 configuration *_dc.json_* on disk, mount the volume on container *c1* at
 *_/data_*, and update the deployment configuration on the server:
 
 ----
-$ oc volume -f dc.json --add --name=v1 --type=persistentVolumeClaim \
+$ oc set volume -f dc.json --add --name=v1 --type=persistentVolumeClaim \
   --claim-name=pvc1 --mount-path=/data --containers=c1
 ----
 
@@ -189,7 +189,7 @@ Add volume *v1* based on Git repository
 all replication controllers:
 
 ----
-$ oc volume rc --all --add --name=v1 \
+$ oc set volume rc --all --add --name=v1 \
   --source='{"gitRepo": {
                 "repository": "https://github.com/namespace1/project1",
                 "revision": "5125c45f9f563"
@@ -202,7 +202,7 @@ Updating existing volumes or volume mounts is the same as
 xref:adding-volumes[adding volumes], but with the `--overwrite` option:
 
 ----
-$ oc volume <object_type>/<name> --add --overwrite [options]
+$ oc set volume <object_type>/<name> --add --overwrite [options]
 ----
 
 [discrete]
@@ -213,21 +213,21 @@ Replace existing volume *v1* for replication controller *r1* with existing
 persistent volume claim *pvc1*:
 
 ----
-$ oc volume rc/r1 --add --overwrite --name=v1 --type=persistentVolumeClaim --claim-name=pvc1
+$ oc set volume rc/r1 --add --overwrite --name=v1 --type=persistentVolumeClaim --claim-name=pvc1
 ----
 
 Change deployment configuration *d1* mount point to *_/opt_* for volume *v1*:
 
 ----
-$ oc volume dc/d1 --add --overwrite --name=v1 --mount-path=/opt
+$ oc set volume dc/d1 --add --overwrite --name=v1 --mount-path=/opt
 ----
 
 [[removing-volumes]]
 == Removing Volumes
 To remove a volume or volume mount from pod templates:
 
 ----
-$ oc volume <object_type>/<name> --remove [options]
+$ oc set volume <object_type>/<name> --remove [options]
 ----
 
 .Supported Options for Removing Volumes
@@ -265,28 +265,28 @@ values: `json`, `yaml`.
 Remove a volume *v1* from deployment configuration *d1*:
 
 ----
-$ oc volume dc/d1 --remove --name=v1
+$ oc set volume dc/d1 --remove --name=v1
 ----
 
 Unmount volume *v1* from container *c1* for deployment configuration *d1* and
 remove the volume *v1* if it is not referenced by any containers on *d1*:
 
 ----
-$ oc volume dc/d1 --remove --name=v1 --containers=c1
+$ oc set volume dc/d1 --remove --name=v1 --containers=c1
 ----
 
 Remove all volumes for replication controller *r1*:
 
 ----
-$ oc volume rc/r1 --remove --confirm
+$ oc set volume rc/r1 --remove --confirm
 ----
 
 [[listing-volumes]]
 == Listing Volumes
 To list volumes or volume mounts for pods or pod templates:
 
 ----
-$ oc volume <object_type>/<name> --list [options]
+$ oc set volume <object_type>/<name> --list [options]
 ----
 
 List volume supported options:
@@ -312,12 +312,12 @@ character.
 List all volumes for pod *p1*:
 
 ----
-$ oc volume pod/p1 --list
+$ oc set volume pod/p1 --list
 ----
 
 List volume *v1* defined on all deployment configurations:
 ----
-$ oc volume dc --all --name=v1
+$ oc set volume dc --all --name=v1
 ----
 
 [[volumes-specifying-a-subpath]]

diff --git a/getting_started/configure_openshift.adoc b/getting_started/configure_openshift.adoc
@@ -87,7 +87,7 @@ $ oc adm policy add-cluster-role-to-user cluster-admin admin
 ----
 +
 // tag::ocadm-note[]
-When running `oc adm` commands, you should run them only from 
+When running `oc adm` commands, you should run them only from
 the first master listed in the Ansible host inventory file,
 by default *_/etc/ansible/hosts_*.
 // end::ocadm-note[]
@@ -246,7 +246,7 @@ now need to add this claim to the registry.
 
 [subs="verbatim,macros"]
 ----
-$ oc volume dc/docker-registry \
+$ oc set volume dc/docker-registry \
     --add --overwrite -t persistentVolumeClaim \
     --claim-name=pass:quotes[_registry-volume-claim_] \
     --name=registry-storage