anchor.diff:  // Module included in the following assemblies:
   //
   // * operators/understanding_olm/olm-packaging-format.adoc
  -// * operators/operator_sdk/osdk-managing-bundle-images.adoc
   
   [id="olm-bundle-format_{context}"]
   = Bundle Format
  
positive.code: Bundle manifests refer to a set of Kubernetes manifests that define the
  deployment and RBAC model of the Operator.
  
  A bundle includes one ClusterServiceVersion (CSV) per directory
  and typically the CRDs that define the owned APIs of the CSV in its `manifest/`
  directory, though additional objects may be included:
  
  .Example Bundle Format layout
  [source,terminal]
  
negative.code: ├── manifests
  │   ├── etcdcluster.crd.yaml
  │   └── etcdoperator.clusterserviceversion.yaml
  │   └── secret.yaml
  │   └── configmap.yaml
  └── metadata
      └── annotations.yaml
      └── dependencies.yaml
  ----
  
  [discrete]
  [id="olm-bundle-format-manifests-optional_{context}"]
  === Optional objects
  
  The following objects can also be optionally included in the `/manifests`
  directory of a bundle:
  
  .Supported optional objects
  * Secrets
  * ConfigMaps
  
  When these optional objects are included in a bundle, Operator Lifecycle Manager
  (OLM) can create them from the bundle and manage their lifecycle along with the
  CSV:
  
  .Lifecycle for optional objects
  * When the CSV is deleted, OLM deletes the optional object.
  * When the CSV is upgraded:
  ** If the name of the optional object is the same, OLM updates it in place.
  ** If the name of the optional object has changed between versions, OLM deletes and
  recreates it.
  
  [id="olm-bundle-format-annotations_{context}"]
  == Annotations
  
  A bundle also includes an `annotations.yaml` file in its `/metadata` directory.
  This file defines higher level aggregate data that helps describe the format and
  package information about how the bundle should be added into an index of
  bundles:
  
  .Example `annotations.yaml`
  [source,yaml]
  