From fc034a3c2945eb393d6b7a34522efeb9299dc840 Mon Sep 17 00:00:00 2001 From: Maciej Szulik Date: Thu, 9 Aug 2018 12:01:44 +0200 Subject: [PATCH] Switch to oc set env/volume, since oc env/volume is now removed --- admin_guide/high_availability.adoc | 6 ++-- admin_guide/managing_networking.adoc | 2 +- admin_guide/pruning_resources.adoc | 4 +-- architecture/networking/routes.adoc | 4 +-- cli_reference/basic_cli_operations.adoc | 10 +++--- cli_reference/cli_by_example_content.adoc | 24 ++++++------- .../topics/proc_restoring-data-new-pvc.adoc | 2 +- .../topics/pvc_backup_and_restore.adoc | 6 ++-- dev_guide/dev_tutorials/maven_tutorial.adoc | 2 +- dev_guide/volumes.adoc | 36 +++++++++---------- getting_started/configure_openshift.adoc | 4 +-- install_config/redeploying_certificates.adoc | 22 ++++++------ .../deploy_registry_existing_clusters.adoc | 4 +-- .../extended_registry_configuration.adoc | 14 ++++---- .../securing_and_exposing_registry.adoc | 4 +-- .../router/customized_haproxy_router.adoc | 4 +-- .../router/default_haproxy_router.adoc | 12 +++---- install_config/router/proxy_protocol.adoc | 4 +-- .../azure_blob_docker_registry_example.adoc | 2 +- .../gluster_backed_registry.adoc | 2 +- 20 files changed, 84 insertions(+), 84 deletions(-) diff --git a/admin_guide/high_availability.adoc b/admin_guide/high_availability.adoc index d13d39818821..1454da7832ec 100644 --- 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 index 37798484f11d..9db674439a35 100644 --- 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 index c6f27e130c94..426e7dd9c93b 100644 --- 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 index cd2ac1904650..e35cc4bb0e5e 100644 --- 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 index d5e631ae62ec..d3b887e30674 100644 --- a/cli_reference/basic_cli_operations.adoc +++ b/cli_reference/basic_cli_operations.adoc @@ -235,7 +235,7 @@ $ oc edit / \ === volume Modify a xref:../dev_guide/volumes.adoc#dev-guide-volumes[volume]: ---- -$ oc volume / [--option] +$ oc set volume / [--option] ---- [[oc-label]] @@ -655,9 +655,9 @@ $ 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 @@ -665,12 +665,12 @@ 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 index e0d4a03a9a86..f527088c7571 100644 --- 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= + $ oc set volume pod/p1 --add -m /repo --source= // 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 index b7f3bd7821ca..a9666a979afe 100644 --- 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 index bc585d345c49..5b486f34ec0a 100644 --- 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 index 212e271137c7..14e995f69525 100644 --- 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 index 8edd718ae6ab..6c5e54cb59cc 100644 --- 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 +$ oc set volume ---- This topic uses the form `__/__` for `__` @@ -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 / --add [options] +$ oc set volume / --add [options] ---- [[add-options]] @@ -165,14 +165,14 @@ 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 @@ -180,7 +180,7 @@ 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 / --add --overwrite [options] +$ oc set volume / --add --overwrite [options] ---- [discrete] @@ -213,13 +213,13 @@ 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]] @@ -227,7 +227,7 @@ $ oc volume dc/d1 --add --overwrite --name=v1 --mount-path=/opt To remove a volume or volume mount from pod templates: ---- -$ oc volume / --remove [options] +$ oc set volume / --remove [options] ---- .Supported Options for Removing Volumes @@ -265,20 +265,20 @@ 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]] @@ -286,7 +286,7 @@ $ oc volume rc/r1 --remove --confirm To list volumes or volume mounts for pods or pod templates: ---- -$ oc volume / --list [options] +$ oc set volume / --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 index 9f14bf882120..49919ae86d2e 100644 --- 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 diff --git a/install_config/redeploying_certificates.adoc b/install_config/redeploying_certificates.adoc index e4dcadf7af2d..6b016dd76a74 100644 --- a/install_config/redeploying_certificates.adoc +++ b/install_config/redeploying_certificates.adoc @@ -329,8 +329,8 @@ file. To use the current CA, skip this step. openshift_master_ca_certificate={'certfile': '', 'keyfile': ''} ---- + -If the CA certificate is issued by an intermediate CA, the bundled certificate must contain -the full chain (the intermediate and root certificates) for the CA in order to validate child certificates. +If the CA certificate is issued by an intermediate CA, the bundled certificate must contain +the full chain (the intermediate and root certificates) for the CA in order to validate child certificates. + For example: + @@ -392,8 +392,8 @@ $ ansible-playbook -i \ [IMPORTANT] ==== -After running this playbook, you need to regenerate any xref:../dev_guide/secrets.adoc#service-serving-certificate-secrets[service signing certificate or key pairs] -by deleting existing secrets that contain service serving certificates or removing and re-adding +After running this playbook, you need to regenerate any xref:../dev_guide/secrets.adoc#service-serving-certificate-secrets[service signing certificate or key pairs] +by deleting existing secrets that contain service serving certificates or removing and re-adding annotations to appropriate services. ==== @@ -497,7 +497,7 @@ deprecated in favor of using secrets). variables: + ---- -$ oc env dc/docker-registry --list +$ oc set env dc/docker-registry --list ---- .. If they do not exist, skip this step. If they do, create the following `ClusterRoleBinding`: @@ -526,7 +526,7 @@ oc create -f - Then, run the following to remove the environment variables: + ---- -$ oc env dc/docker-registry OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER- +$ oc set env dc/docker-registry OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER- ---- . Set the following environment variables locally to make later commands less @@ -550,7 +550,7 @@ $ oc adm ca create-server-cert \ ---- + Run `oc adm` commands only from the first master listed in the Ansible host inventory file, -by default *_/etc/ansible/hosts_*. +by default *_/etc/ansible/hosts_*. . Update the `registry-certificates` secret with the new registry certificates: + @@ -592,7 +592,7 @@ deprecated in favor of using service serving certificate secret. variables: + ---- -$ oc env dc/router --list +$ oc set env dc/router --list ---- .. If those variables exist, create the following `ClusterRoleBinding`: @@ -621,7 +621,7 @@ oc create -f - .. If those variables exist, run the following command to remove them: + ---- -$ oc env dc/router OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER- +$ oc set env dc/router OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER- ---- . Obtain a certificate. @@ -669,7 +669,7 @@ $ cat router.crt /etc/origin/master/ca.crt router.key > router.pem $ oc export secret router-certs > ~/old-router-certs-secret.yaml ---- -. Create a new secret to hold the new certificate and key, and replace the +. Create a new secret to hold the new certificate and key, and replace the contents of the existing secret: + ---- @@ -678,7 +678,7 @@ $ oc create secret tls router-certs --cert=router.pem \ <1> oc replace -f - ---- <1> *_router.pem_* is the file that contains the concatenation of the -certificates that you generated. +certificates that you generated. . Remove the following annotations from the `router` service: + diff --git a/install_config/registry/deploy_registry_existing_clusters.adoc b/install_config/registry/deploy_registry_existing_clusters.adoc index 2b6cb3f5b49c..f9cbc48fb99a 100644 --- a/install_config/registry/deploy_registry_existing_clusters.adoc +++ b/install_config/registry/deploy_registry_existing_clusters.adoc @@ -123,7 +123,7 @@ persistent storage method of your choice]. For example, to use an existing persistent volume claim: ---- -$ oc volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \ +$ oc set volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \ --claim-name= --overwrite ---- @@ -423,7 +423,7 @@ $ oc create secret generic console-secret \ . Add the secrets to the *registry-console* deployment configuration: + ---- -$ oc volume dc/registry-console --add --type=secret \ +$ oc set volume dc/registry-console --add --type=secret \ --secret-name=console-secret -m /etc/cockpit/ws-certs.d ---- + diff --git a/install_config/registry/extended_registry_configuration.adoc b/install_config/registry/extended_registry_configuration.adoc index 2860c1c7992c..fc6746fe84c9 100644 --- a/install_config/registry/extended_registry_configuration.adoc +++ b/install_config/registry/extended_registry_configuration.adoc @@ -224,7 +224,7 @@ configuration to mount the custom configuration file at *_/etc/docker/registry/_*: + ---- -$ oc volume dc/docker-registry --add --type=configmap \ +$ oc set volume dc/docker-registry --add --type=configmap \ --configmap-name=registry-config -m /etc/docker/registry/ ---- + @@ -564,12 +564,12 @@ capability also makes it possible for you to pull images that reside on a registry they do not have credentials to access, as long as you have access to the image stream tag that references the image. -You must ensure that your registry has appropriate certificates to trust -any external registries you do a pullthrough against. The certificates need to be placed -in the *_/etc/pki/tls/certs_* directory on the pod. You can mount the certificates -using a xref:../../dev_guide/configmaps.adoc#configmaps-creating-from-directories[configuration map] -or xref:../../dev_guide/secrets.adoc#dev-guide-secrets[secret]. Note that the entire *_/etc/pki/tls/certs_* directory -must be replaced. You must include the new certificates and replace the system certificates +You must ensure that your registry has appropriate certificates to trust +any external registries you do a pullthrough against. The certificates need to be placed +in the *_/etc/pki/tls/certs_* directory on the pod. You can mount the certificates +using a xref:../../dev_guide/configmaps.adoc#configmaps-creating-from-directories[configuration map] +or xref:../../dev_guide/secrets.adoc#dev-guide-secrets[secret]. Note that the entire *_/etc/pki/tls/certs_* directory +must be replaced. You must include the new certificates and replace the system certificates in your secret or configuration map that you mount. Note that by default image stream tags use a reference policy type of `*Source*` diff --git a/install_config/registry/securing_and_exposing_registry.adoc b/install_config/registry/securing_and_exposing_registry.adoc index d67316b4bd2e..3dd1d6a59e24 100644 --- a/install_config/registry/securing_and_exposing_registry.adoc +++ b/install_config/registry/securing_and_exposing_registry.adoc @@ -108,7 +108,7 @@ $ oc rollout pause dc/docker-registry . Add the secret volume to the registry deployment configuration: + ---- -$ oc volume dc/docker-registry --add --type=secret \ +$ oc set volume dc/docker-registry --add --type=secret \ --secret-name=registry-certificates -m /etc/secrets ---- + @@ -297,7 +297,7 @@ route "docker-registry" created <2> <2> The route name is identical to the service name. . Next, you must trust the certificates being used for the registry on your host -system to allow the host to push and pull images. The certificates referenced +system to allow the host to push and pull images. The certificates referenced were created when you secured your registry. + ---- diff --git a/install_config/router/customized_haproxy_router.adoc b/install_config/router/customized_haproxy_router.adoc index 03ff7f956ab8..61e5b9215e33 100644 --- a/install_config/router/customized_haproxy_router.adoc +++ b/install_config/router/customized_haproxy_router.adoc @@ -508,14 +508,14 @@ The `customrouter` ConfigMap now contains a copy of the modified . Modify the router deployment configuration to mount the ConfigMap as a file and point the `TEMPLATE_FILE` environment variable to it. -This can be done via `oc set env` and `oc volume` commands, +This can be done via `oc set env` and `oc set volume` commands, or alternatively by editing the router deployment configuration. + Using `oc` commands:: + [source,bash] ---- -$ oc volume dc/router --add --overwrite \ +$ oc set volume dc/router --add --overwrite \ --name=config-volume \ --mount-path=/var/lib/haproxy/conf/custom \ --source='{"configMap": { "name": "customrouter"}}' diff --git a/install_config/router/default_haproxy_router.adoc b/install_config/router/default_haproxy_router.adoc index 407813ef4dcc..4d89ecdf5e38 100644 --- a/install_config/router/default_haproxy_router.adoc +++ b/install_config/router/default_haproxy_router.adoc @@ -259,7 +259,7 @@ rest are handled by another. . After xref:../../install_config/router/index.adoc#install-config-router-overview[creating a router], use the `ROUTE_LABELS` environment variable to tag the router: + ---- -$ oc env dc/ ROUTE_LABELS="key=value" +$ oc set env dc/ ROUTE_LABELS="key=value" ---- . Add the label to the desired routes: @@ -950,7 +950,7 @@ To manually redeploy the router certificates: . Check to see if a secret containing the default router certificate was added to the router: + ---- -$ oc volumes dc/router +$ oc set volume dc/router deploymentconfigs/router secret/router-certs as server-certificate @@ -962,7 +962,7 @@ If the certificate is added, skip the following step and overwrite the secret. . Make sure that you have a default certificate directory set for the following variable `DEFAULT_CERTIFICATE_DIR`: + ---- -$ oc env dc/router --list +$ oc set env dc/router --list DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/private ---- @@ -970,7 +970,7 @@ DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/private If not, create the directory using the following command: + ---- -$ oc env dc/router DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/private +$ oc set env dc/router DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/private ---- . Export the certificate to PEM format: @@ -994,7 +994,7 @@ To create a new secret, run the following commands: ---- $ oc create secret generic router-certs --from-file=tls.crt=custom-router.crt --from-file=tls.key=custom-router.key --type=kubernetes.io/tls -$ oc volume dc/router --add --mount-path=/etc/pki/tls/private --secret-name='router-certs' --name router-certs +$ oc set volume dc/router --add --mount-path=/etc/pki/tls/private --secret-name='router-certs' --name router-certs ---- . Deploy the router. @@ -1470,7 +1470,7 @@ link:https://cbonte.github.io/haproxy-dconv/1.5/configuration.html#9[HAProxy rou or CSV download. These metrics include the HAProxy native metrics and some controller metrics. -When you create a router using the following command, {product-title} makes metrics available in Prometheus format on the stats port, by default 1936. +When you create a router using the following command, {product-title} makes metrics available in Prometheus format on the stats port, by default 1936. ---- $ oc adm router --service-account=router diff --git a/install_config/router/proxy_protocol.adoc b/install_config/router/proxy_protocol.adoc index bfff039242ed..f9eabb315435 100644 --- a/install_config/router/proxy_protocol.adoc +++ b/install_config/router/proxy_protocol.adoc @@ -58,7 +58,7 @@ expect the PROXY protocol for incoming connections: .Enable the PROXY Protocol ---- -$ oc env dc/router ROUTER_USE_PROXY_PROTOCOL=true +$ oc set env dc/router ROUTER_USE_PROXY_PROTOCOL=true ---- Set the variable to any value other than `true` or `TRUE` to disable the PROXY @@ -66,7 +66,7 @@ protocol: .Disable the PROXY Protocol ---- -$ oc env dc/router ROUTER_USE_PROXY_PROTOCOL=false +$ oc set env dc/router ROUTER_USE_PROXY_PROTOCOL=false ---- If you enable the PROXY protocol in the router, you must configure your load diff --git a/install_config/storage_examples/azure_blob_docker_registry_example.adoc b/install_config/storage_examples/azure_blob_docker_registry_example.adoc index e9b91ec0a8b7..3053512d2336 100644 --- a/install_config/storage_examples/azure_blob_docker_registry_example.adoc +++ b/install_config/storage_examples/azure_blob_docker_registry_example.adoc @@ -76,7 +76,7 @@ $ oc create secret generic registry-config --from-file=config.yaml=registryconfi + [source,bash] ---- -$ oc volume dc/docker-registry --add --type=secret \ +$ oc set volume dc/docker-registry --add --type=secret \ --secret-name=registry-config -m /etc/docker/registry/ ---- diff --git a/install_config/storage_examples/gluster_backed_registry.adoc b/install_config/storage_examples/gluster_backed_registry.adoc index dc5b90d95f29..a43f531ed4a7 100644 --- a/install_config/storage_examples/gluster_backed_registry.adoc +++ b/install_config/storage_examples/gluster_backed_registry.adoc @@ -62,7 +62,7 @@ instructions for troubleshooting before continuing. Then, attach the PVC: ---- -$ oc volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \ +$ oc set volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \ --claim-name=gluster-claim --overwrite ----