Merge pull request #11291 from bmcelvee/PR10102-Follow-up

PR10102-Follow-up Minor Edits

Author: bmcelvee

dev_guide/managing_images.adoc

@@ -364,7 +364,7 @@ ifdef::openshift-enterprise,openshift-origin[]
 [[using-is-with-k8s]]
 == Using Image Streams with Kubernetes Resources
 
-Image Streams, being {product-title} native resources, work out of the box with
+Image streams, being {product-title} native resources, work out of the box with
 all the rest of native resources available in {product-title}, such as
 xref:../dev_guide/builds/index.adoc#dev-guide-how-builds-work[builds] or
 xref:../dev_guide/deployments/basic_deployment_operations.adoc#dev-guide-basic-deployment-operations[deployments].
@@ -551,35 +551,40 @@ By default, all service accounts in a project have rights to pull any image in
 the same project, and the *builder* service account has rights to push any image
 in the same project.
 
-ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,atomic-registry[]
+ifdef::openshift-origin,openshift-enterprise,openshift-dedicated[]
+[[managing-images-listing-repositories]]
 === Listing repositories
 
-Listing of repositories (or rather ImageStream names) is supported via `/v2/_catalog` endpoint as
-documented
-link:https://github.com/docker/distribution/blob/master/docs/spec/api.md#listing-repositories[upstream].
-The only requirement is that the authenticated user must have `list` rights on the `imagestreams`
-in the whole cluster.
+Listing of repositories, or image stream names, is supported by the
+`/v2/_catalog` endpoint.
 
-Here is one example of granting a permission to list ImageStreams to a user:
+The only requirement is that the authenticated user must have `list` rights on
+the `imagestreams` in the whole cluster.
 
+To grant a permission to list image streams to a user, run:
 ----
 $ oc adm policy add-cluster-role-to-user registry-viewer user
 ----
 
-.A CLI example of listing repositories
+To list repositories:
 ----
 $ oc login -u user
 $ curl -v -u unused:$(oc whoami -t) https://<registry_server>:<port>/v2/_catalog?n=100
 ----
 
 [IMPORTANT]
 ====
-This API call is very expensive for a high number of image streams in the cluster. We strongly
-recommend to use
+This API call is very expensive for a high number of image streams in the cluster.
+It is recommend to use
+ifdef::openshift-enterprise,openshift-dedicated[]
+pagination
+endif::openshift-enterprise,openshift-dedicated[]
+ifdef::openshift-origin[]
 link:https://github.com/docker/distribution/blob/master/docs/spec/api.md#pagination[pagination]
+endif::openshift-origin[]
 instead of listing all image streams.
 ====
-endif::openshift-origin,openshift-enterprise,openshift-dedicated,atomic-registry[]
+endif::openshift-origin,openshift-enterprise,openshift-dedicated[]
 
 ifdef::openshift-origin,openshift-online,openshift-enterprise,openshift-dedicated[]
 [[using-image-pull-secrets]]
@@ -1015,7 +1020,7 @@ done by adding the CA certificate or registry certificate to the host system
 running the registry import controller (typically the master node).
 
 You must add the certificate or CA certificate to `/etc/pki/tls/certs` or `/etc/pki/ca-trust`,
-respectively, on the host system. You also need to run the `update-ca-trust` command 
+respectively, on the host system. You also need to run the `update-ca-trust` command
 on Red Hat distributions followed by a restart of the master services to pick up
 the certificate changes.
 
@@ -1025,7 +1030,7 @@ the certificate changes.
 An image stream can be configured to import tag and image metadata from the
 internal registry, but from a different project. The recommended method for
 this is to use the `oc tag` command as shown in xref:adding-tag[Adding Tags to
-Image Streams]:
+image streams]:
 
 ----
 $ oc tag <source_project>/<image_stream>:<tag> <new_image_stream>:<new_tag>