Fixes bugs for registry content

_topic_map.yml

@@ -293,7 +293,7 @@ Topics:
 - Name: Accessing the registry
   File: accessing-the-registry
   Distros: openshift-enterprise,openshift-origin
-- Name: Securing and exposing the registry
+- Name: Exposing the registry
   File: securing-exposing-registry
   Distros: openshift-enterprise,openshift-origin
 ---

applications/pruning-objects.adoc

@@ -24,7 +24,7 @@ include::modules/pruning-builds.adoc[leveloffset=+1]
 include::modules/pruning-images.adoc[leveloffset=+1]
 .Additional resources
 - xref:../registry/accessing-the-registry.adoc#accessing-the-registry[Accessing the registry]
-- xref:../registry/securing-exposing-registry.adoc#securing-exposing-registry[Securing and exposing the registry]
+- xref:../registry/securing-exposing-registry.adoc#securing-exposing-registry[Exposing the registry]
 
 include::modules/pruning-hard-pruning-registry.adoc[leveloffset=+1]
 include::modules/pruning-cronjobs.adoc[leveloffset=+1]

modules/pruning-images.adoc

@@ -47,8 +47,8 @@ routes are not created by default. See
 xref:../registry/configuring-registry-operator.adoc#configuring-registry-operator[Image
 Registry Operator in {product-title}] for information on how to create a
 registry route and see
-xref:../registry/securing-exposing-registry.adoc#securing-exposing-registry[Securing
-and exposing the registry] for details on how to expose the registry service.
+xref:../registry/securing-exposing-registry.adoc#securing-exposing-registry[Exposing
+the registry] for details on how to expose the registry service.
 
 .Prune images CLI configuration options
 [cols="4,8",options="header"]

modules/registry-accessing-directly.adoc

@@ -1,70 +1,47 @@
 // Module included in the following assemblies:
 //
-// * assembly/registry
+// * registry/accessing-the-registry.adoc
 
 [id="registry-accessing-directly_{context}"]
-= Accessing registry directly
+= Accessing registry directly from the cluster
 
-You can access the registry directly to invoke `podman` commands. This allows
-you to push images to or pull them from the integrated registry directly using
-operations like `podman-push` or `podman-pull`. To do so, you must be logged in
-to the registry using the `podman-login` command. The operations you can perform
-depend on your user permissions, as described in the following sections.
+You can access the registry from inside the cluster.
 
-.Prerequisites
+.Procedure
 
-* For any direct access, you must have a regular user for your preferred identity
-provider.
-** A regular user can generate an access token required for logging in to
-the registry.
-** System users, such as *system:admin*, cannot obtain access tokens
-and, therefore, cannot access the registry directly.
-+
-For example, if you are using `HTPASSWD` authentication, you can create one
-using the following command:
-+
-----
-# htpasswd /etc/origin/openshift-htpasswd <user_name>
-----
+Access the registry from the cluster by using internal routes:
 
-* For pulling images, for example when using the `podman-pull` command,
-the user must have the *registry-viewer* role. To add this role:
+. Access the node by getting the node's address:
 +
 ----
-$ oc policy add-role-to-user registry-viewer <user_name>
+$ oc get nodes
+$ oc debug nodes/<node_address>
 ----
-
-* For writing or pushing images, for example when using the `podman-push` command,
-the user must have the *registry-editor* role. To add this role:
 +
-----
-$ oc policy add-role-to-user registry-editor <user_name>
-----
-
-.Procedure
-
-. Log in to the registry directly:
-
-.. Ensure you are logged in to {product-title} as a *regular user*:
+. Log in to the container image registry by using your access token:
 +
 ----
-$ oc login
+$ oc login -u kubeadmin -p <password_from_install_log>
+$ podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000
 ----
-
-.. Log in to the container image registry by using your access token:
++
+You should see a message confirming login, such as:
 +
 ----
-$ podman-login -u openshift -p $(oc whoami -t) <registry_ip>:<port>
+Login Succeeded!
 ----
 +
 [NOTE]
 ====
-You can pass any value for the username, the token contains all necessary
-information. Passing a username that contains colons will result in a login
+You can pass any value for the user name; the token contains all necessary
+information. Passing a user name that contains colons will result in a login
 failure.
+
+Since the Image Registry Operator creates the route, it will likely be similar to
+`default-route-openshift-image-registry.<cluster_name>`.
 ====
 +
-. Perform `podman-pull` and `podman-push` operations against your registry:
+. Perform `podman pull` and `podman push` operations against your registry:
 +
 [IMPORTANT]
 ====
@@ -96,30 +73,27 @@ In the following examples, use:
 .. Pull an arbitrary image:
 +
 ----
-$ podman-pull name.io/image
+$ podman pull name.io/image
 ----
 
 .. Tag the new image with the form `<registry_ip>:<port>/<project>/<image>`.
 The project name must appear in this pull specification for {product-title} to
 correctly place and later access the image in the registry:
 +
 ----
-$ podman-tag name.io/image 172.30.124.220:5000/openshift/image
+$ podman tag name.io/image image-registry.openshift-image-registry.svc:5000/openshift/image
 ----
 +
 [NOTE]
 ====
-Your regular user must have the *system:image-builder* role for the specified
+You must have the `system:image-builder` role for the specified
 project, which allows the user to write or push an image. Otherwise, the
-`podman-push` in the next step will fail. To test, you can create a new project
+`podman push` in the next step will fail. To test, you can create a new project
 to push the image.
 ====
 
 .. Push the newly-tagged image to your registry:
 +
 ----
-$ podman-push 172.30.124.220:5000/openshift/image
-...
-cf2616975b4a: Image successfully pushed
-Digest: sha256:3662dd821983bc4326bee12caec61367e7fb6f6a3ee547cbaff98f77403cab55
+$ podman push image-registry.openshift-image-registry.svc:5000/openshift/image
 ----

modules/registry-operator-default-crd.adoc

@@ -4,19 +4,19 @@
 
 
 [id="registry-operator-default-crd_{context}"]
-= Securing the Image Registry with the Custom Resource Definition
+= Enable the Image Registry default route with the Custom Resource Definition
 
 In {product-title}, the `Registry` Operator controls the registry feature. The
 Operator is defined by the `configs.imageregistry.operator.openshift.io` Custom
 Resource Definition (CRD).
 
-If you must automatically secure the Image Registry, patch the Image Registry
-Operator CRD.
+If you need to automatically enable the Image Registry default route, patch the
+Image Registry Operator CRD.
 
 .Procedure
 
 * Patch the Image Registry Operator CRD:
 +
 ----
-$ oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"defaultRoute":false}}'
+$ oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"defaultRoute":true}}'
 ----