Add pkgman-to-bundle OSDK docs

Author: adellape

_topic_map.yml

@@ -1283,6 +1283,8 @@ Topics:
     File: osdk-monitoring-prometheus
   - Name: Configuring leader election
     File: osdk-leader-election
+  - Name: Migrating package manifest projects to bundle format
+    File: osdk-pkgman-to-bundle
   - Name: Operator SDK CLI reference
     File: osdk-cli-ref
   - Name: Migrating to Operator SDK v0.1.0

cli_reference/opm-cli.adoc

@@ -8,7 +8,7 @@ toc::[]
 include::modules/olm-about-opm.adoc[leveloffset=+1]
 .Additional resources
 
-* See xref:../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Operator Framework packaging formats] for more information about the Bundle Format.
+* See xref:../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Operator Framework packaging formats] for more information about the bundle format.
 * To create a bundle image using the Operator SDK, see
 xref:../operators/operator_sdk/osdk-working-bundle-images.adoc#osdk-working-bundle-images[Working with bundle images].
 

modules/olm-about-catalogs.adoc

@@ -7,11 +7,11 @@
 
 An Operator catalog is a repository of metadata that Operator Lifecycle Manager (OLM) can query to discover and install Operators and their dependencies on a cluster. OLM always installs Operators from the latest version of a catalog. As of {product-title} 4.6, Red Hat-provided catalogs are distributed using _index images_.
 
-An index image, based on the Operator Bundle Format, is a containerized snapshot of a catalog. It is an immutable artifact that contains the database of pointers to a set of Operator manifest content. A catalog can reference an index image to source its content for OLM on the cluster.
+An index image, based on the Operator bundle format, is a containerized snapshot of a catalog. It is an immutable artifact that contains the database of pointers to a set of Operator manifest content. A catalog can reference an index image to source its content for OLM on the cluster.
 
 [NOTE]
 ====
-Starting in {product-title} 4.6, index images provided by Red Hat replace the App Registry catalog images, based on the deprecated Package Manifest Format, that are distributed for previous versions of {product-title} 4. While App Registry catalog images are not distributed by Red Hat for {product-title} 4.6 and later, custom catalog images based on the Package Manifest Format are still supported.
+Starting in {product-title} 4.6, index images provided by Red Hat replace the App Registry catalog images, based on the deprecated package manifest format, that are distributed for previous versions of {product-title} 4. While App Registry catalog images are not distributed by Red Hat for {product-title} 4.6 and later, custom catalog images based on the package manifest format are still supported.
 ====
 
 As catalogs are updated, the latest versions of Operators change, and older versions may be removed or altered. In addition, when OLM runs on an {product-title} cluster in a restricted network environment, it is unable to access the catalogs directly from the Internet to pull the latest content.

modules/olm-about-opm.adoc

@@ -6,6 +6,6 @@
 [id="olm-about-opm_{context}"]
 = About opm
 
-The `opm` CLI tool is provided by the Operator Framework for use with the Operator Bundle Format. This tool allows you to create and maintain catalogs of Operators from a list of bundles, called an _index_, that are similar to software repositories. The result is a container image, called an _index image_, which can be stored in a container registry and then installed on a cluster.
+The `opm` CLI tool is provided by the Operator Framework for use with the Operator bundle format. This tool allows you to create and maintain catalogs of Operators from a list of bundles, called an _index_, that are similar to software repositories. The result is a container image, called an _index image_, which can be stored in a container registry and then installed on a cluster.
 
 An index contains a database of pointers to Operator manifest content that can be queried through an included API that is served when the container image is run. On {product-title}, Operator Lifecycle Manager (OLM) can use the index image as a catalog by referencing it in a `CatalogSource` object, which polls the image at regular intervals to enable frequent updates to installed Operators on the cluster.

modules/olm-accessing-images-private-registries.adoc

@@ -11,7 +11,7 @@ Other images required by an Operator or its Operands might require access to pri
 
 The following types of images should be considered when determining whether Operators managed by OLM have appropriate pull access:
 
-Index or catalog images:: A `CatalogSource` object can reference an index image or a catalog image, which are catalog sources packaged as container images hosted in images registries. Index images use the Bundle Format and reference bundle images, while catalog images use the Package Manifest Format. If an index or catalog image is hosted in a private registry, a secret can be used to enable pull access.
+Index or catalog images:: A `CatalogSource` object can reference an index image or a catalog image, which are catalog sources packaged as container images hosted in images registries. Index images use the bundle format and reference bundle images, while catalog images use the package manifest format. If an index or catalog image is hosted in a private registry, a secret can be used to enable pull access.
 
 Bundle images:: Operator bundle images are metadata and manifests packaged as container images that represent a unique version of an Operator. If any bundle images referenced in a catalog source are hosted in one or more private registries, a secret can be used to enable pull access.
 

modules/olm-building-operator-catalog-image.adoc

@@ -10,9 +10,9 @@ ifndef::openshift-origin[]
 endif::[]
 
 [id="olm-building-operator-catalog-image_{context}"]
-= Building a Package Manifest Format catalog image
+= Building a package manifest format catalog image
 
-Cluster administrators can build a custom Operator catalog image based on the Package Manifest Format to be used by Operator Lifecycle Manager (OLM). The catalog image can be pushed to a container image registry that supports link:https://docs.docker.com/registry/spec/manifest-v2-2/[Docker v2-2]. For a cluster on a restricted network, this registry can be a registry that the cluster has network access to, such as a mirror registry created during a restricted network cluster installation.
+Cluster administrators can build a custom Operator catalog image based on the package manifest format to be used by Operator Lifecycle Manager (OLM). The catalog image can be pushed to a container image registry that supports link:https://docs.docker.com/registry/spec/manifest-v2-2/[Docker v2-2]. For a cluster on a restricted network, this registry can be a registry that the cluster has network access to, such as a mirror registry created during a restricted network cluster installation.
 
 For this example, the procedure assumes use of a mirror registry that has access to both your network and the Internet.
 

modules/olm-bundle-format.adoc

@@ -3,9 +3,9 @@
 // * operators/understanding/olm/olm-packaging-format.adoc
 
 [id="olm-bundle-format_{context}"]
-= Bundle Format
+= Bundle format
 
-The _Bundle Format_ for Operators is a new packaging format introduced by the Operator Framework. To improve scalability and to better enable upstream users hosting their own catalogs, the Bundle Format specification simplifies the distribution of Operator metadata.
+The _bundle format_ for Operators is a new packaging format introduced by the Operator Framework. To improve scalability and to better enable upstream users hosting their own catalogs, the bundle format specification simplifies the distribution of Operator metadata.
 
 An Operator bundle represents a single version of an Operator. On-disk _bundle manifests_ are containerized and shipped as a _bundle image_, which is a non-runnable container image that stores the Kubernetes manifests and Operator metadata. Storage and distribution of the bundle image is then managed using existing container tools like `podman` and `docker` and container registries such as Quay.
 
@@ -29,7 +29,7 @@ Bundle manifests refer to a set of Kubernetes manifests that define the deployme
 
 A bundle includes one CSV per directory and typically the CRDs that define the owned APIs of the CSV in its `/manifests` directory.
 
-.Example Bundle Format layout
+.Example bundle format layout
 [source,terminal]
 ----
 etcd

modules/olm-mirroring-catalog.adoc

@@ -184,7 +184,7 @@ If your cluster uses an `ImageContentSourcePolicy` object to configure repositor
 +
 [IMPORTANT]
 ====
-If you used the `--manifests-only` flag during the mirroring process and want to further trim the subset of packages to be mirrored, see the steps in the "Mirroring a Package Manifest Format catalog image" procedure about modifying your `mapping.txt` file and using the file with the `oc image mirror` command. After following those further actions, you can continue this procedure.
+If you used the `--manifests-only` flag during the mirroring process and want to further trim the subset of packages to be mirrored, see the steps in the "Mirroring a package manifest format catalog image" procedure about modifying your `mapping.txt` file and using the file with the `oc image mirror` command. After following those further actions, you can continue this procedure.
 ====
 --
 

modules/olm-mirroring-package-manifest-catalog.adoc

@@ -3,14 +3,14 @@
 // * operators/admin/olm-managing-custom-catalogs.adoc
 
 [id="olm-mirroring-package-manifest-catalog_{context}"]
-= Mirroring a Package Manifest Format catalog image
+= Mirroring a package manifest format catalog image
 
-Cluster administrators can mirror a custom Operator catalog image based on the Package Manifest Format into a registry and use a catalog source to load the content onto their cluster. For this example, the procedure uses a custom `redhat-operators` catalog image previously built and pushed to a supported registry.
+Cluster administrators can mirror a custom Operator catalog image based on the package manifest format into a registry and use a catalog source to load the content onto their cluster. For this example, the procedure uses a custom `redhat-operators` catalog image previously built and pushed to a supported registry.
 
 .Prerequisites
 
 * Workstation with unrestricted network access
-* A custom Operator catalog image based on the Package Manifest Format pushed to a supported registry
+* A custom Operator catalog image based on the package manifest format pushed to a supported registry
 * `oc` version 4.3.5+
 * `podman` version 1.9.3+
 * Access to mirror registry that supports link:https://docs.docker.com/registry/spec/manifest-v2-2/[Docker v2-2]

modules/olm-package-manifest-format-catalogsource.adoc

@@ -3,13 +3,13 @@
 // * operators/admin/olm-managing-custom-catalogs.adoc
 
 [id="olm-package-manifest-format-catalogsource_{context}"]
-= Creating a catalog from a Package Manifest Format catalog image
+= Creating a catalog from a package manifest format catalog image
 
-Cluster administrators use a custom Operator catalog image based on the Package Manifest Format to create a catalog source that loads the Operator content onto their cluster. For this example, the procedure uses a custom `redhat-operators` catalog image previously built and pushed to a supported registry.
+Cluster administrators use a custom Operator catalog image based on the package manifest format to create a catalog source that loads the Operator content onto their cluster. For this example, the procedure uses a custom `redhat-operators` catalog image previously built and pushed to a supported registry.
 
 .Prerequisites
 
-* A custom Operator catalog image based on the Package Manifest Format pushed to a supported registry
+* A custom Operator catalog image based on the package manifest format pushed to a supported registry
 * `oc` version 4.3.5+
 
 .Procedure