Added Chris's image topics to the map

Author: vikram-redhat

_topic_map.yml

@@ -143,6 +143,12 @@ Name: Images
 Dir: openshift_images
 Distros: openshift-*
 Topics:
+- Name: Understand containers, images and image streams
+  File: images-understand
+- Name: Creating images
+  File: images-create
+- Name: Managing image streams
+  File: image-streams-manage
 - Name: Using templates
   File: using-templates
 - Name: Using Ruby on Rails

applications/operator_sdk/osdk-ansible.adoc

@@ -47,6 +47,6 @@ include::modules/osdk-ansible-managing-cr-status.adoc[leveloffset=+1]
 == Additional resources
 
 - See
-xref:../applications/operator_sdk/osdk-appendices.adoc#osdk-project-scaffolding-layout_operator-appendices[Appendices]
+xref:../../applications/operator_sdk/osdk-appendices.adoc#osdk-project-scaffolding-layout_operator-appendices[Appendices]
 to learn about the project directory structures created by the Operator SDK.
 - link:https://blog.openshift.com/reaching-for-the-stars-with-ansible-operator/[Reaching for the Stars with Ansible Operator] - Red Hat OpenShift Blog

applications/operator_sdk/osdk-getting-started.adoc

@@ -23,7 +23,7 @@ include::modules/managing-memcached-operator-using-olm.adoc[leveloffset=+1]
 == Additional resources
 
 - See
-xref:../applications/operator_sdk/osdk-appendices.adoc#osdk-project-scaffolding-layout_operator-appendices[Appendices]
+xref:../../applications/operator_sdk/osdk-appendices.adoc#osdk-project-scaffolding-layout_operator-appendices[Appendices]
 to learn about the project directory structures created by the Operator SDK.
 
 ifdef::openshift-origin[]

applications/operator_sdk/osdk-helm.adoc

@@ -19,5 +19,5 @@ include::modules/osdk-building-helm-operator.adoc[leveloffset=+1]
 == Additional resources
 
 - See
-xref:../applications/operator_sdk/osdk-appendices.adoc#osdk-project-scaffolding-layout_operator-appendices[Appendices]
+xref:../../applications/operator_sdk/osdk-appendices.adoc#osdk-project-scaffolding-layout_operator-appendices[Appendices]
 to learn about the project directory structures created by the Operator SDK.

modules/image-stream-configure.adoc

@@ -10,13 +10,6 @@ ifdef::openshift-origin,openshift-online,openshift-enterprise,openshift-dedicate
 An image stream object file contains the following elements.
 endif::openshift-origin,openshift-online,openshift-enterprise,openshift-dedicated[]
 
-ifdef::openshift-origin,openshift-online,openshift-enterprise,openshift-dedicated[]
-[NOTE]
-====
-See the xref:../../dev_guide/managing_images.adoc#dev-guide-managing-images[Developer Guide] for details
-on managing images and image streams.
-====
-endif::openshift-origin,openshift-online,openshift-enterprise,openshift-dedicated[]
 
 [[image-stream-object-definition]]
 .Image Stream Object Definition
@@ -60,13 +53,6 @@ status:
 <4> The SHA identifier that this image stream tag previously referenced. Can be used to rollback to an older image.
 <5> The image stream tag name.
 
-For a sample build configuration that references an image stream, see xref:../../dev_guide/builds/index.adoc#defining-a-buildconfig[What Is a BuildConfig?]
-in the `Strategy` stanza of the configuration.
-
-For a sample deployment configuration that references an image stream,
-see xref:../../dev_guide/deployments/how_deployments_work.adoc#creating-a-deployment-configuration[Creating a Deployment Configuration]
-in the `Strategy` stanza of the configuration.
-
 [[image-stream-image]]
 == Using image stream images
 
@@ -86,8 +72,7 @@ The image stream image consists of the image stream name and image ID from the r
 <image-stream-name>@<image-id>
 ----
 
-To refer to the image in the
-xref:image-stream-object-definition[image stream object example above], the image stream image looks like:
+To refer to the image in the image stream object example, the image stream image looks like:
 
 ----
 origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
@@ -108,7 +93,7 @@ history stack. The image previously occupying the top position will be available
 the second position, and so forth. This allows for easy rollbacks to make tags point to
 historical images again.
 
-The following image stream tag is from the xref:image-stream-object-definition[image stream object example above]:
+The following image stream tag is from the image stream object example earlier:
 
 .Image Stream Tag with Two Images in its History
 
@@ -140,7 +125,7 @@ For example, the `latest` image stream tags that ship with {product-title} are t
 Tracking tags are limited to a single image stream and cannot reference other image streams.
 ====
 
-You can create your own image stream tags for your own needs. See the xref:../../dev_guide/managing_images.adoc#tag-naming[Recommended Tagging Conventions].
+You can create your own image stream tags for your own needs.
 
 The image stream tag is composed of the name of the image stream and a tag, separated by a colon:
 
@@ -150,7 +135,7 @@ The image stream tag is composed of the name of the image stream and a tag, sepa
 
 For example, to refer to the
 `sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d` image
-in the  xref:image-stream-object-definition[image stream object example above], the image stream tag
+in the  image stream object example earlier, the image stream tag
 would be:
 
 ----
@@ -167,14 +152,12 @@ Image stream triggers allow your Builds and Deployments to be automatically invo
 For example, Builds and Deployments can be automatically started when an image stream tag is modified.
 This is achieved by monitoring that particular image stream tag and notifying the Build or Deployment when a change is detected.
 
-include::dev_guide/deployments/basic_deployment_operations.adoc[tag=image-change-trig]
 
 [[image-stream-mappings]]
 == Using image stream mappings
 
-When the
-xref:../../architecture/infrastructure_components/image_registry.adoc#integrated-openshift-registry[integrated
-registry] receives a new image, it creates and sends an image stream mapping
+When the integrated
+registry receives a new image, it creates and sends an image stream mapping
 to {product-title}, providing the image's project, name,
 tag, and image metadata.
 
@@ -189,14 +172,6 @@ metadata about each image, such as commands, entry point, and environment
 variables. Images in {product-title} are immutable and the maximum name length
 is 63 characters.
 
-ifdef::openshift-origin,openshift-online,openshift-enterprise,openshift-dedicated[]
-[NOTE]
-====
-See the xref:../../dev_guide/managing_images.adoc#dev-guide-managing-images[Developer Guide] for details
-on manually tagging images.
-====
-endif::openshift-origin,openshift-online,openshift-enterprise,openshift-dedicated[]
-
 The following image stream mapping example results in an image being tagged as
 *test/origin-ruby-sample:latest*:
 
@@ -316,8 +291,7 @@ image:
 [[image-stream-mappings-working]]
 = Working with image streams
 
-The following sections describe how to use image streams and image stream tags. For more information on working with
-image streams, see xref:../../dev_guide/managing_images.adoc#dev-guide-managing-images[Managing Images].
+The following sections describe how to use image streams and image stream tags.
 
 [[image-stream-mappings-working-getting]]
 == Getting information about image streams
@@ -445,7 +419,6 @@ Tag python:3.6 set to docker.io/python:3.6.0.
 ----
 
 If the external image is secured, you will need to create a secret with credentials for accessing that registry.
-See xref:../../dev_guide/managing_images.adoc#private-registries[Importing Images from Private Registries] for more details.
 
 [[image-stream-mappings-working-updating]]
 == Updating an image stream tag
@@ -498,7 +471,7 @@ Tag python:3.6 set to import docker.io/python:3.6.0 periodically.
 ----
 
 This command causes {product-title} to periodically update this particular image stream tag. This period is a
-xref:../../install_config/master_node_configuration.adoc#master-config-image-config[cluster-wide setting] set to 15 minutes by default.
+cluster-wide setting set to 15 minutes by default.
 
 To remove the periodic check, re-run above command but omit the `--scheduled` flag. This will reset its behavior to default.
 

modules/image-stream-use.adoc

@@ -5,15 +5,14 @@
 
 = Using image streams
 
-An image stream and its associated tags provide an abstraction for referencing
-xref:../../architecture/core_concepts/containers_and_images.adoc#docker-images[container images] from within {product-title}.
+An image stream and its associated tags provide an abstraction for referencing container images from within {product-title}.
 The image stream and its tags allow you to see what images are available
 and ensure that you are using the specific image you need even if the image in the repository changes.
 
 Image streams do not contain actual image data, but present a single virtual view of related images, similar to an image repository.
 
-You can  configure xref:../../dev_guide/builds/triggering_builds.adoc#image-change-triggers[Builds] and
-xref:../../dev_guide/deployments/basic_deployment_operations.adoc#image-change-trigger[Deployments] to watch an image stream
+You can  configure Builds and
+Deployments to watch an image stream
 for notifications when new images are added and react by performing a Build or Deployment, respectively.
 
 For example, if a Deployment is using a certain image and a new version of that image is created,
@@ -24,8 +23,7 @@ then even if the container image in the container image registry is updated, the
 
 The source images can be stored in any of the following:
 
-* {product-title}'s xref:../../architecture/infrastructure_components/image_registry.adoc#integrated-openshift-registry[integrated
-registry]
+* {product-title}'s integrated registry
 * An external registry, for example `registry.redhat.io` or `hub.docker.com`
 * Other image streams in the {product-title} cluster
 
@@ -69,14 +67,14 @@ Using image streams has several significant benefits:
 * You can trigger Builds and Deployments when a new image is pushed to the registry. Also,
 {product-title} has generic triggers for other resources (such as Kubernetes objects).
 
-* You can xref:../../dev_guide/managing_images.adoc#importing-tag-and-image-metadata[mark a tag for periodic re-import].
+* You can mark a tag for periodic re-import.
 If the source image has changed, that change is picked up and reflected in the image stream, which triggers the Build and/or Deployment flow, depending upon the Build or Deployment configuration.
 
 * You can share images using fine-grained access control and quickly distribute images across your teams.
 
 * If the source image changes, the image stream tag will still point to a known-good version of the image, ensuring that your application will not break unexpectedly.
 
-* You can xref:../../admin_guide/manage_rbac.adoc#admin-guide-manage-rbac[configure security] around who can view and use the images through permissions on the image stream objects.
+* You can configure security around who can view and use the images through permissions on the image stream objects.
 
 * Users that lack permission to read or list images on the cluster level can still retrieve the images tagged in a project using image streams.
 

modules/images-create-guide-general.adoc

@@ -174,9 +174,7 @@ advertising a path on the system that could be used by another process, such as
 It is best to avoid setting default passwords. Many people will extend the image
 and forget to remove or change the default password. This can lead to security
 issues if a user in production is assigned a well-known password. Passwords
-should be configurable using an environment variable instead. See the
-xref:use-env-vars[Using Environment Variables for Configuration] topic for more
-information.
+should be configurable using an environment variable instead. 
 
 If you do choose to set a default password, ensure that an appropriate warning
 message is displayed when the container is started. The message should inform
@@ -188,10 +186,7 @@ as what environment variable to set.
 
 It is best to avoid running *sshd* in your image. You can use the `podman exec` or `docker exec`
 command to access containers that are running on the local host. Alternatively,
-you can use the
-xref:../dev_guide/executing_remote_commands.adoc#dev-guide-executing-remote-commands[`oc
-exec`] command or the
-xref:../dev_guide/ssh_environment.adoc#dev-guide-ssh-environment[`oc rsh` ]
+you can use the `oc exec` command or the `oc rsh`
 command to access containers that are running on the {product-title} cluster.
 Installing and running *sshd* in your image opens up additional vectors for
 attack and requirements for security patching.

modules/images-create-guide-openshift.adoc

@@ -34,9 +34,6 @@ application as output.
 For example, this https://github.com/sclorg/s2i-python-container[Python image]
 defines S2I scripts for building various versions of Python applications.
 
-For more details about how to write S2I scripts for your image, see the
-xref:s2i.adoc#creating-images-s2i[S2I Requirements] topic.
-
 [discrete]
 [[use-uid]]
 == Support arbitrary user ids
@@ -102,14 +99,7 @@ Lastly, the final *USER* declaration in the `Dockerfile` should specify the user
 ID (numeric value) and not the user name. This allows {product-title} to
 validate the authority the image is attempting to run with and prevent running
 images that are trying to run as root, because running containers as a
-privileged user exposes
-ifdef::openshift-enterprise,openshift-origin[]
-xref:../install/prerequisites.adoc#security-warning[potential
-security holes].
-endif::[]
-ifdef::openshift-dedicated[]
-potential security holes.
-endif::[]
+privileged user exposes potential security holes.
 If the image does not specify a *USER*, it inherits the *USER*
 from the parent image.
 
@@ -118,13 +108,11 @@ ifdef::openshift-enterprise,openshift-origin[]
 ====
 If your S2I image does not include a *USER* declaration with a numeric user,
 your builds will fail by default. In order to allow images that use either named
-users or the root (*0*) user to build in {product-title}, you can
-xref:../admin_guide/manage_scc.adoc#grant-access-to-the-privileged-scc[add the
-project's builder service account]
+users or the root (*0*) user to build in {product-title}, you can add the
+project's builder service account
 (*system:serviceaccount:<your-project>:builder*) to the *privileged* security
 context constraint (SCC). Alternatively, you can allow all images to
-xref:../admin_guide/manage_scc.adoc#enable-images-to-run-with-user-in-the-dockerfile[run
-as any user].
+run as any user.
 ====
 endif::[]
 
@@ -135,7 +123,7 @@ endif::[]
 For cases where your image needs to communicate with a service provided by
 another image, such as a web front end image that needs to access a database
 image to store and retrieve data, your image should consume an {product-title}
-xref:../architecture/core_concepts/pods_and_services.adoc#services[service].
+service.
 Services provide a static endpoint for access which does not change as
 containers are stopped, started, or moved. In addition, services provide load
 balancing for requests.
@@ -186,8 +174,8 @@ volumes that would be mounted into the container at runtime. However, if you
 elect to do it this way you must ensure that your image provides clear error
 messages on startup when the necessary volume or configuration is not present.
 
-This topic is related to the xref:use-services[Using Services for Inter-image
-Communication] topic in that configuration like datasources should be defined in
+This topic is related to the Using Services for Inter-image
+Communication topic in that configuration like datasources should be defined in
 terms of environment variables that provide the service endpoint information.
 This allows an application to dynamically consume a datasource service that is
 defined in the {product-title} environment without modifying the application
@@ -214,9 +202,6 @@ allowing {product-title} to create a better experience for developers using your
 image. For example, you can add metadata to provide helpful descriptions of your
 image, or offer suggestions on other images that may also be needed.
 
-See the xref:metadata.adoc#creating-images-metadata[Image Metadata] topic for more information on
-supported metadata and how to define them.
-
 [discrete]
 == Clustering
 
@@ -245,21 +230,18 @@ running container and retrieve or view the log file.
 [discrete]
 == Liveness and readiness probes
 
-Document example
-xref:../dev_guide/application_health.adoc#container-health-checks-using-probes[liveness
-and readiness probes] that can be used with your image. These probes will allow
+Document example liveness and readiness probes that can be used with your image. These probes will allow
 users to deploy your image with confidence that traffic will not be routed to
 the container until it is prepared to handle it, and that the container will be
 restarted if the process gets into an unhealthy state.
 
 [discrete]
 == Templates
 
-Consider providing an example xref:../dev_guide/templates.adoc#dev-guide-templates[template] with
+Consider providing an example template with
 your image. A template will give users an easy way to quickly get your image
 deployed with a working configuration. Your template should include the
-xref:../dev_guide/application_health.adoc#container-health-checks-using-probes[liveness
-and readiness probes] you documented with the image, for completeness.
+liveness and readiness probes you documented with the image, for completeness.
 
 
 .Additional resources

modules/images-create-s2i-scripts.adoc

@@ -11,7 +11,7 @@ executable inside the builder image. S2I supports multiple options providing
 `assemble`/`run`/`save-artifacts` scripts. All of these locations are checked on
 each build in the following order:
 
-. A script xref:../dev_guide/builds/build_strategies.adoc#override-builder-image-scripts[specified in the BuildConfig]
+. A script specified in the BuildConfig
 . A script found in the application source `.s2i/bin` directory
 . A script found at the default image URL (`io.openshift.s2i.scripts-url` label)
 
@@ -70,8 +70,6 @@ image is working correctly. The proposed flow of that process is:
 . Run `s2i build` again to verify the *_save-artifacts_* and *_assemble_* scripts save and restore artifacts functionality. (optional)
 . Run the image to verify the test application is working.
 
-See the xref:s2i_testing.adoc#creating-images-s2i-testing[Testing S2I Images] topic for more information.
-
 NOTE: The suggested location to put the test application built by your
 *_test/run_* script is the *_test/test-app_* directory in your image repository.
 See the https://github.com/openshift/source-to-image/blob/master/docs/cli.md#sti-create[S2I documentation]

modules/images-create-s2i.adoc

@@ -7,13 +7,12 @@
 [id="images-create-s2i_{context}"]
 
 = Creating images from source code with s2i
-xref:../architecture/core_concepts/builds_and_image_streams.adoc#source-build[Source-to-Image
-(S2I)] is a framework that makes it easy to write images that take application
+Source-to-Image
+(S2I) is a framework that makes it easy to write images that take application
 source code as an input and produce a new image that runs the assembled
 application as output.
 
 The main advantage of using S2I for building reproducible container images is the
 ease of use for developers. As a builder image author, you must understand two
 basic concepts in order for your images to provide the best possible S2I performance:
-xref:build-process[the build process] and xref:s2i-scripts[S2I scripts].
-
+the build process and S2I scripts.