Merge pull request #38914 from Amrita42/OSDOCS-2567

jeana-redhat · web-flow · commit 005774a963a8 · 2021-12-14T07:57:27.000-05:00
OSDOCS-2567: Overview of images
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
@@ -1203,7 +1203,7 @@ Dir: registry
 Distros: openshift-enterprise,openshift-origin
 Topics:
 - Name: Registry overview
-  File: index  
+  File: index
 - Name: Image Registry Operator in OpenShift Container Platform
   File: configuring-registry-operator
   Distros: openshift-enterprise
@@ -1496,14 +1496,14 @@ Name: Images
 Dir: openshift_images
 Distros: openshift-enterprise,openshift-origin,openshift-online
 Topics:
+- Name: Overview of images
+  File: index
 - Name: Configuring the Cluster Samples Operator
   File: configuring-samples-operator
   Distros: openshift-enterprise,openshift-origin
 - Name: Using the Cluster Samples Operator with an alternate registry
   File: samples-operator-alt-registry
   Distros: openshift-enterprise,openshift-origin
-- Name: Understanding containers, images, and imagestreams
-  File: images-understand
 - Name: Creating images
   File: create-images
 - Name: Managing images
diff --git a/modules/application-health-about.adoc b/modules/application-health-about.adoc
@@ -32,7 +32,7 @@ kills and restarts the container.
 Startup probe::
 A _startup probe_ indicates whether the application within a container is started. All other probes are disabled until the startup succeeds. If the startup probe does not succeed within a specified time period, the kubelet kills the container, and the container is subject to the pod `restartPolicy`.
 +
-Some applications can require additional start-up time on their first initialization. You can use a startup probe with a liveness or readiness probe to delay that probe long enough to handle lengthy start-up time using the `failureThreshold` and `periodSeconds` parameters.
+Some applications can require additional startup time on their first initialization. You can use a startup probe with a liveness or readiness probe to delay that probe long enough to handle lengthy start-up time using the `failureThreshold` and `periodSeconds` parameters.
 +
 For example, you can add a startup probe, with a `failureThreshold` of 30 failures and a `periodSeconds` of 10 seconds (30 * 10s = 300s) for a maximum of 5 minutes, to a liveness probe. After the startup probe succeeds the first time, the liveness probe takes over.
 
diff --git a/modules/deployments-exec-cmd-in-container.adoc b/modules/deployments-exec-cmd-in-container.adoc
@@ -5,7 +5,7 @@
 [id="deployments-exe-cmd-in-container_{context}"]
 = Executing commands inside a container
 
-You can add a command to a container, which modifies the container's start-up behavior by overruling the image's `ENTRYPOINT`. This is different from a lifecycle hook, which instead can be run once per deployment at a specified time.
+You can add a command to a container, which modifies the container's startup behavior by overruling the image's `ENTRYPOINT`. This is different from a lifecycle hook, which instead can be run once per deployment at a specified time.
 
 .Procedure
 
diff --git a/modules/images-imagestream-use.adoc b/modules/images-imagestream-use.adoc
@@ -3,7 +3,7 @@
 // * openshift_images/image-streams-managing.adoc
 
 [id="images-imagestream-use_{context}"]
-= Using image streams
+= Why use imagestreams
 
 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.
 
diff --git a/modules/images-other-jenkins-config-kubernetes.adoc b/modules/images-other-jenkins-config-kubernetes.adoc
@@ -13,7 +13,7 @@ Both the Maven and Node.js agent images are automatically configured as Kubernet
 
 The Jenkins image also provides auto-discovery and auto-configuration of additional agent images for the Kubernetes plug-in.
 
-With the {product-title} sync plug-in, the Jenkins image on Jenkins start-up searches for the following within the project that it is running or the projects specifically listed in the plug-in's configuration:
+With the {product-title} sync plug-in, the Jenkins image on Jenkins startup searches for the following within the project that it is running or the projects specifically listed in the plug-in's configuration:
 
 * Image streams that have the label `role` set to `jenkins-agent`.
 * Image stream tags that have the annotation `role` set to `jenkins-agent`.
diff --git a/modules/images-other-jenkins-env-var.adoc b/modules/images-other-jenkins-env-var.adoc
@@ -70,7 +70,7 @@ By default, the JVM sets the initial heap size.
 |Default: `300000` - 5 minutes
 
 |`OVERRIDE_PV_CONFIG_WITH_IMAGE_CONFIG`
-|When running this image with an {product-title} persistent volume (PV) for the Jenkins configuration directory, the transfer of configuration from the image to the PV is performed only the first time the image starts because the PV is assigned when the persistent volume claim (PVC) is created. If you create a custom image that extends this image and updates configuration in the custom image after the initial start-up, the configuration is not copied over unless you set this environment variable to `true`.
+|When running this image with an {product-title} persistent volume (PV) for the Jenkins configuration directory, the transfer of configuration from the image to the PV is performed only the first time the image starts because the PV is assigned when the persistent volume claim (PVC) is created. If you create a custom image that extends this image and updates configuration in the custom image after the initial startup, the configuration is not copied over unless you set this environment variable to `true`.
 |Default: `false`
 
 |`OVERRIDE_PV_PLUGINS_WITH_IMAGE_PLUGINS`
diff --git a/modules/installation-osp-balancing-external-loads.adoc b/modules/installation-osp-balancing-external-loads.adoc
@@ -7,7 +7,7 @@
 
 Configure an external load balancer in {rh-openstack-first} to use your own load balancer, resolve external networking needs, or scale beyond what the default {product-title} load balancer can provide.
 
-The load balancer serves ports 6443, 443, and 80 to any users of the system. Port 22623 serves Ignition start-up configurations to the {product-title} machines and must not be reachable from outside the cluster.
+The load balancer serves ports 6443, 443, and 80 to any users of the system. Port 22623 serves Ignition startup configurations to the {product-title} machines and must not be reachable from outside the cluster.
 
 .Prerequisites
 
diff --git a/modules/machine-config-overview.adoc b/modules/machine-config-overview.adoc
@@ -18,7 +18,7 @@ A node can have multiple labels applied that indicate its type, such as `master`
 ====
 
 * Some machine configuration must be in place before {product-title} is installed to disk. In most cases, this can be accomplished by creating
-a machine config that is injected directly into the {product-title} installer process, instead of running as a post-installation machine config. In other cases, you might need to do bare metal installation where you pass kernel arguments at {product-title} installer start-up, to do such things as setting per-node individual IP addresses or advanced disk partitioning.
+a machine config that is injected directly into the {product-title} installer process, instead of running as a post-installation machine config. In other cases, you might need to do bare metal installation where you pass kernel arguments at {product-title} installer startup, to do such things as setting per-node individual IP addresses or advanced disk partitioning.
 
 * MCO manages items that are set in machine configs. Manual changes you do to your systems will not be overwritten by MCO, unless MCO is explicitly told to manage a conflicting file. In other words, MCO only makes specific updates you request, it does not claim control over the whole node.
 
diff --git a/modules/nw-osp-configuring-external-load-balancer.adoc b/modules/nw-osp-configuring-external-load-balancer.adoc
@@ -26,7 +26,7 @@ to use an external load balancer in place of the default load balancer.
 
 * Load balance the application ports, 443 and 80, between all of the compute nodes.
 
-* On your load balancer, port 22623, which is used to serve ignition start-up configurations to nodes, is not exposed outside of the cluster.
+* On your load balancer, port 22623, which is used to serve ignition startup configurations to nodes, is not exposed outside of the cluster.
 
 * Your load balancer must be able to access every machine in your cluster. Methods to allow this access include:
 ** Attaching the load balancer to the cluster's machine subnet.
diff --git a/modules/samples-operator-overview.adoc b/modules/samples-operator-overview.adoc
@@ -49,7 +49,7 @@ The Cluster Samples Operator is bootstrapped as `Managed` by default or if globa
 
 Certain circumstances result in the Cluster Samples Operator bootstrapping itself as `Removed` including:
 
-* If the Cluster Samples Operator cannot reach link:https://registry.redhat.io[registry.redhat.io] after three minutes on initial start-up after a clean installation.
+* If the Cluster Samples Operator cannot reach link:https://registry.redhat.io[registry.redhat.io] after three minutes on initial startup after a clean installation.
 * If the Cluster Samples Operator detects it is on an IPv6 network.
 * If the xref:../openshift_images/image-configuration.html#images-configuration-parameters_image-configuration[image controller configuration parameters] prevent the creation of image streams by using the default image registry, or by using the image registry specified by the xref:../openshift_images/configuring-samples-operator.html#samples-operator-configuration_configuring-samples-operator[`samplesRegistry` setting].
 
diff --git a/openshift_images/index.adoc b/openshift_images/index.adoc
@@ -0,0 +1,69 @@
+[id="overview-of-images"]
+= Overview of images
+include::modules/common-attributes.adoc[]
+:context: overview-of-images
+
+toc::[]
+
+[id="about-containers-images-and-image-streams"]
+== Understanding containers, images, and image streams
+Containers, images, and image streams are important concepts to understand when you set out to create and manage containerized software.
+An image holds a set of software that is ready to run, while a container is a running instance of a container image.
+An image stream provides a way of storing different versions of the same basic image.
+Those different versions are represented by different tags on the same image name.
+
+include::modules/images-about.adoc[leveloffset=+1]
+You can xref:../openshift_images/create-images.adoc#creating-images[create], xref:../openshift_images/managing_images/managing-images-overview.adoc#managing-images-overview[manage], and xref:../openshift_images/using_images/using-images-overview.adoc#using-images-overview[use] container images.
+
+include::modules/images-image-registry-about.adoc[leveloffset=+1]
+
+include::modules/images-container-repository-about.adoc[leveloffset=+1]
+
+include::modules/images-tag.adoc[leveloffset=+1]
+
+include::modules/images-id.adoc[leveloffset=+1]
+
+include::modules/containers-about.adoc[leveloffset=+1]
+
+include::modules/images-imagestream-use.adoc[leveloffset=+1]
+
+You can xref:../openshift_images/image-streams-manage.adoc#managing-image-streams[manage] image streams, xref:../openshift_images/using-imagestreams-with-kube-resources.adoc#using-imagestreams-with-kube-resources[use image streams with Kubernetes resources], and xref:../openshift_images/triggering-updates-on-imagestream-changes.adoc#triggering-updates-on-imagestream-changes[trigger updates on image stream updates].
+
+include::modules/images-imagestream-tag.adoc[leveloffset=+1]
+
+include::modules/images-imagestream-image.adoc[leveloffset=+1]
+
+include::modules/images-imagestream-trigger.adoc[leveloffset=+1]
+
+[id="how-you-can-use-the-cluster-samples-operator"]
+== How you can use the Cluster Samples Operator
+
+During the initial startup, the Operator creates the default samples resource to initiate the creation of the image streams and templates.
+You can use the Cluster Samples Operator to manage the sample image streams and templates stored in the `openshift` namespace.
+
+As a cluster administrator, you can use the Cluster Samples Operator to:
+
+** xref:../openshift_images/configuring-samples-operator.adoc#configuring-samples-operator[Configure the Operator].
+** xref:../openshift_images/samples-operator-alt-registry.adoc#samples-operator-alt-registry[Use the Operator with an alternate registry].
+
+
+[id="about-templates"]
+== About templates
+
+A template is a definition of an object to be replicated.
+You can use xref:../openshift_images/using-templates.adoc#using-templates[templates] to build and deploy configurations.
+
+[id="how-you-can-use-ruby-on-rails"]
+== How you can use Ruby on Rails
+
+As a developer, you can use xref:../openshift_images/templates-using-ruby-on-rails.adoc#templates-using-ruby-on-rails[Ruby on Rails] to:
+
+** Write your application:
+*** Set up a database.
+*** Create a welcome page.
+*** Configure your application for {product-title}.
+*** Store your application in Git.
+** Deploy your application in {product-title}:
+*** Create the database service.
+*** Create the frontend service.
+*** Create a route for your application.
diff --git a/security/container_security/security-container-content.adoc b/security/container_security/security-container-content.adoc
@@ -23,5 +23,5 @@ include::modules/security-container-content-scanning.adoc[leveloffset=+1]
 // Integrating external scanning tools with OpenShift
 include::modules/security-container-content-external-scanning.adoc[leveloffset=+1]
 .Additional resources
-* xref:../../openshift_images/images-understand.adoc#images-imagestream-use_images-understand[Image stream objects]
+* xref:../../openshift_images/index.adoc#overview-of-images[Image stream objects]
 // * xref::../../rest_api/index.adoc#rest-api[{product-title} {product-version} REST APIs]
diff --git a/welcome/index.adoc b/welcome/index.adoc
@@ -158,7 +158,7 @@ xref:../applications/working_with_helm_charts/understanding-helm.adoc#understand
 
 - **xref:../cicd/builds/understanding-image-builds.adoc#understanding-image-builds[Understand image builds]**: Choose from different build strategies (Docker, S2I, custom, and pipeline) that can include different kinds of source materials (from places like Git repositories, local binary inputs, and external artifacts). Then, follow examples of build types from basic builds to advanced builds.
 
-- **xref:../openshift_images/images-understand.adoc#understanding-images[Create container images]**: A container image is the most basic building block in {product-title} (and Kubernetes) applications. Defining image streams lets you gather multiple versions of an image in one place as you continue its development. S2I containers let you insert your source code into a base container that is set up to run code of a particular type, such as Ruby, Node.js, or Python.
+- **xref:../openshift_images/index.adoc#overview-of-images[Create container images]**: A container image is the most basic building block in {product-title} (and Kubernetes) applications. Defining image streams lets you gather multiple versions of an image in one place as you continue its development. S2I containers let you insert your source code into a base container that is set up to run code of a particular type, such as Ruby, Node.js, or Python.
 
 - **xref:../applications/deployments/what-deployments-are.adoc#what-deployments-are[Create deployments]**:  Use `Deployment` and `DeploymentConfig` objects to exert fine-grained management over applications.
  xref:../applications/deployments/managing-deployment-processes.adoc#deployment-operations[Manage deployments] using the *Workloads* page or OpenShift CLI (`oc`). Learn xref:../applications/deployments/deployment-strategies.adoc#deployment-strategies[rolling, recreate, and custom] deployment strategies.
diff --git a/welcome/learn_more_about_openshift.adoc b/welcome/learn_more_about_openshift.adoc
@@ -121,7 +121,7 @@ Use the following sections to find content to help you learn about and use {prod
 | xref:../operators/understanding/olm-what-operators-are.adoc#olm-what-operators-are[Operators]
 
 |
-| xref:../openshift_images/images-understand.adoc#understanding-images[Images]
+| xref:../openshift_images/index.adoc#overview-of-images[Images]
 
 |
 | xref:../cli_reference/developer_cli_odo/understanding-odo.adoc#understanding-odo[Developer-focused CLI]

Original file line number	Diff line number	Diff line change
`@@ -32,7 +32,7 @@ kills and restarts the container.`
`32`	`32`	`Startup probe::`
`33`	`33`	A _startup probe_ indicates whether the application within a container is started. All other probes are disabled until the startup succeeds. If the startup probe does not succeed within a specified time period, the kubelet kills the container, and the container is subject to the pod `restartPolicy`.
`34`	`34`	`+`
`35`		-Some applications can require additional start-up time on their first initialization. You can use a startup probe with a liveness or readiness probe to delay that probe long enough to handle lengthy start-up time using the `failureThreshold` and `periodSeconds` parameters.
	`35`	+Some applications can require additional startup time on their first initialization. You can use a startup probe with a liveness or readiness probe to delay that probe long enough to handle lengthy start-up time using the `failureThreshold` and `periodSeconds` parameters.
`36`	`36`	`+`
`37`	`37`	For example, you can add a startup probe, with a `failureThreshold` of 30 failures and a `periodSeconds` of 10 seconds (30 * 10s = 300s) for a maximum of 5 minutes, to a liveness probe. After the startup probe succeeds the first time, the liveness probe takes over.
`38`	`38`