Follow-up edits to PR#3409

Author: ahardin-rh

admin_guide/pruning_resources.adoc

@@ -208,6 +208,7 @@ nor `--keep-younger-than`.
 prune:
 
 [[image-prune-conditions]]
+*Image Prune Conditions*
 
 * Remove any image "managed by {product-title}" (images with the annotation
 `*openshift.io/image.managed*`) that was created at least
@@ -276,20 +277,19 @@ $ oadm prune images --prune-over-size-limit --confirm
 ----
 
 [[image-pruning-problems]]
-=== Image pruning problems
+=== Image Pruning Problems
 
-If your images keep pilling up and prune command removes just a small portion
-of what you would expect, make sure you understand
+If your images keep accumulating and the `prune` command removes just a small
+portion of what you expect, ensure that you understand
 xref:image-prune-conditions[the conditions] that must apply for an image to be
 considered a candidate for pruning.
 
-Especially, ensure that images you want removed occur at higher positions in
-each
+Especially ensure that images you want removed occur at higher positions in each
 xref:../architecture/core_concepts/builds_and_image_streams.adoc#image-stream-tag[tag
 history] than your chosen tag revisions threshold. For example, consider an old
 and obsolete image named `sha:abz`. By running the following command in
-namespace `N`, where the image is tagged, you will see the image is tagged
-three times in a single image stream named `myapp`:
+namespace `N`, where the image is tagged, you will see the image is tagged three
+times in a single image stream named `myapp`:
 
 ----
 $ image_name="sha:abz"
@@ -302,25 +302,31 @@ myapp:v2.1 at position 2 out of 2
 myapp:v2.1-may-2016 at position 0 out of 1
 ----
 
-The image will not be ever pruned, when default options are used, because it
-occurs at position 0 in a history of `myapp:v2.1-may-2016` tag. For an image to
-be considered for pruning, the admin would have to either:
+When default options are used, the image will not ever be pruned because it
+occurs at position `0` in a history of `myapp:v2.1-may-2016` tag. For an image to
+be considered for pruning, the administrator must either:
 
-1. Specify `--keep-tag-revisions=0` to `oadm prune images` command, which is
-very dangerous and should be used with care. It will effectively remove all the
-tags from all the namespaces with underlying images, unless they are younger or
-they are referenced by objects younger than the specified threshold.
-2. Delete all the
+. Specify `--keep-tag-revisions=0` with the `oadm prune images` command.
++
+[CAUTION]
+====
+This action will effectively remove all the tags from all the namespaces with
+underlying images, unless they are younger or they are referenced by objects
+younger than the specified threshold.
+====
+
+. Delete all the
 xref:../architecture/core_concepts/builds_and_image_streams.adoc#image-stream-tag[_istags_]
 where the position is below the revision threshold, which means
 `myapp:v2.1` and `myapp:v2.1-may-2016`.
-3. Move the image further in the history, either by running new builds pushing
-to the same _istag_, or by tagging other image. Unfortunately, this might not
-always be desirable for old release tags.
+
+. Move the image further in the history, either by running new builds pushing to
+the same _istag_, or by tagging other image. Unfortunately, this is not always
+desirable for old release tags.
 
 Tags having a date or time of a particular image's build in their names should
-be avoided, unless the image needs to be preserved for undefined amount of
-time. Such tags tend to have just one image in its history, which effectively
-prevents them from being pruned, ever.
-xref:../dev_guide/managing_images.adoc#tag-naming[Here], you will find more
-information on _istag_ naming.
+be avoided, unless the image needs to be preserved for undefined amount of time.
+Such tags tend to have just one image in its history, which effectively prevents
+them from ever being pruned.
+xref:../dev_guide/managing_images.adoc#tag-naming[Learn more about _istag_
+naming.]

architecture/core_concepts/builds_and_image_streams.adoc

@@ -146,7 +146,7 @@ server is deployed, see xref:../../install_config/configuring_pipeline_execution
 [NOTE]
 ====
 The Jenkins server is not automatically removed,
-even if all Pipeline build configurations are deleted.  
+even if all Pipeline build configurations are deleted.
 It must be manually deleted by the user.
 ====
 
@@ -220,20 +220,18 @@ status:
 [[image-stream-image]]
 === Image Stream Image
 
-Image Stream Image is a virtual resource that allows to retrieve an image from
-a particular _image stream_ where it is tagged. It is often abbreviated as
-_isimage_. It consists of two parts delimited by at sign: `<image stream
-name>@<image name>`. To refer to the image in the
-xref:image-stream-object-definition[example above], the _isimage_ would look
-like this:
+An _image stream image_ is a virtual resource that allows you to retrieve an
+image from a particular _image stream_ where it is tagged. It is often
+abbreviated as _isimage_. It consists of two parts delimited by an at sign:
+`<image stream name>@<image name>`. To refer to the image in the
+xref:image-stream-object-definition[example above], the _isimage_ looks like:
 
 ----
 origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
 ----
 
-Users, without a permission to read or list images on the cluster lever, can still
-retrieve the images tagged in a project, they have access to, using this
-resource.
+Users, without permission to read or list images on the cluster level, can still
+retrieve the images tagged in a project they have access to using this resource.
 
 [[image-stream-tag]]
 === Image Stream Tag
@@ -248,12 +246,12 @@ the second position etc. This allows for easy rollbacks to make tags point to
 historical images again.
 
 The _istag_ is composed of two parts separated by a colon: `<image stream
-name>:<tag>`. _Istag_ refering to the image
+name>:<tag>`. _Istag_ referring to the image
 `sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d` in
 the xref:image-stream-object-definition[example above] would be
 `origin-ruby-sample:latest`.
 
-.Image Stream Tag with two images in its history
+.Image Stream Tag with Two Images in its History
 ====
 [source,yaml]
 ----

dev_guide/application_lifecycle/promoting_applications.adoc

@@ -125,14 +125,14 @@ of the system to facilitate testing of the different scenarios your application
 must support.
 ImageStreams, ImageStreamTags, and ImageStreamImage:: Detailed in the
 xref:dev-guide-promoting-application-images[Images] and
-xref:../../architecture/core_concepts/builds_and_image_streams.adoc#image-streams[image
-streams] sections, these objects are central to the {product-title} additions
-around managing container images. ServiceAccounts and RoleBindings:: Management
-of permissions to other API objects within {product-title}, as well as the
-external services of your enterprise, are intrinsic to managing your
-application. Similar to `Secrets`, the `ServiceAccounts` and `RoleBindingscan`
-objects vary in how they are shared between the different stages of your
-application promotion pipeline based on how your enterprise needs to share or
+xref:../../architecture/core_concepts/builds_and_image_streams.adoc#image-streams[Image
+Streams] sections, these objects are central to the {product-title} additions
+around managing container images.
+ServiceAccounts and RoleBindings:: Management of permissions to other API
+objects within {product-title}, as well as the external services, are intrinsic
+to managing your application. Similar to `Secrets`, the `ServiceAccounts` and
+`RoleBindingscan` objects vary in how they are shared between the different
+stages of your application promotion pipeline based on your needs to share or
 isolate those different environments.
 PersistentVolumeClaims:: Relevant to stateful services like databases, how much
 these are shared between your different application promotion stages directly

dev_guide/builds.adoc

@@ -1178,12 +1178,12 @@ executing the build.
 === Image Source
 
 Additional files can be provided to the build process via images. Input images
-are referenced in the same way the `*From*` and `*To*` image targets are
-defined. This means both container images and
+are referenced in the same way the `From` and `To` image targets are defined.
+This means both container images and
 xref:../architecture/core_concepts/builds_and_image_streams.adoc#image-stream-tag[image
 stream tags] can be referenced. In conjunction with the image, you must provide
-one or more path pairs to indicate the path of the files/directories to copy
-out of the image and the destination to place them in the build context.
+one or more path pairs to indicate the path of the files or directories to copy
+the image and the destination to place them in the build context.
 
 The source path can be any absolute path within the image specified. The
 destination must be a relative directory path. At build time, the image will be

dev_guide/managing_images.adoc

@@ -119,21 +119,19 @@ that prevents the registry client from pulling from such a tag.
 [[tag-naming]]
 === Tag Naming
 
-Images evolve over time and tag reflects it. It always points to the latest
-image built. If there is too much information embedded in a tag name (e.g.
-`v2.0.1-may-2016`), the tag will probably point to just one revision of an
-image and will never be updated. Using default image pruning options, such an
-image will never be removed. Instead, if the tag is named `v2.0`, there's much
-higher probability of more image revisions which means longer
+Images evolve over time and the tag reflects this. It always points to the
+latest image built. If there is too much information embedded in a tag name (for
+example, `v2.0.1-may-2016`), the tag will point to just one revision of an image
+and will never be updated. Using default image pruning options, such an image
+will never be removed. Instead, if the tag is named `v2.0`, more image revisions
+are more likely. This results in longer
 xref:../architecture/core_concepts/builds_and_image_streams.adoc#image-stream-tag[tag
-history] and therefore image pruner will more probably remove old and unsed
-images.
+history] and, therefore, the image pruner will more likely remove old and unused
+images. Refer to
+xref:../admin_guide/pruning_resources.adoc#pruning-images[pruning images] for
+more information.
 
-Refer to xref:../admin_guide/pruning_resources.adoc#pruning-images[pruning
-images] for more information.
-
-Although tag naming convention is up to you, here are a few examples for
-inspiration:
+Although tag naming convention is up to you, here are a few examples:
 
 [width="40%",frame="topbot",options="header"]
 |======================
@@ -143,10 +141,9 @@ inspiration:
 |Base image  |`v1.2-centos7`
 |======================
 
-If you require dates in tag names, you should periodically inspect old and
-unsupported images and _istags_ and remove them. Otherwise you might experience
-increasing resource usage caused by old images.
-
+If you require dates in tag names, periodically inspect old and unsupported
+images and _istags_ and remove them. Otherwise, you might experience increasing
+resource usage caused by old images.
 [[tag-removal]]
 === Removing Tags from Image Streams
 To remove a tag completely from an image stream run: