--- title: Creating ConfigMap objects for the image-based upgrade with the Lifecycle Agent --- # Creating ConfigMap objects for the image-based upgrade with the Lifecycle Agent {#cnf-image-based-upgrade-prep-resources} The Lifecycle Agent needs all your OADP resources, extra manifests, and custom catalog sources wrapped in a `ConfigMap` object to process them for the image-based upgrade. ## Creating OADP ConfigMap objects for the image-based upgrade with Lifecycle Agent {#cnf-image-based-upgrade-prep-oadp_cnf-non-gitops} Create your OADP resources that are used to back up and restore your resources during the upgrade. **Prerequisites** - You have generated a seed image from a compatible seed cluster. - You have created OADP backup and restore resources. - You have created a separate partition on the target cluster for the container images that is shared between stateroots. For more information, see "Configuring a shared container partition for the image-based upgrade". - You have deployed a version of Lifecycle Agent that is compatible with the version used with the seed image. - You have installed the OADP Operator, the `DataProtectionApplication` CR, and its secret on the target cluster. - You have created an S3-compatible storage solution and a ready-to-use bucket with proper credentials configured. For more information, see "About installing OADP". **Procedure** 1. Create the OADP `Backup` and `Restore` CRs for platform artifacts in the same namespace where the OADP Operator is installed, which is `openshift-adp`. 1. If the target cluster is managed by RHACM, add the following `PlatformBackupRestore.yaml` file for backing up and restoring RHACM artifacts: ```yaml apiVersion: velero.io/v1 kind: Backup metadata: name: acm-klusterlet annotations: lca.openshift.io/apply-label: "apps/v1/deployments/open-cluster-management-agent/klusterlet,v1/secrets/open-cluster-management-agent/bootstrap-hub-kubeconfig,rbac.authorization.k8s.io/v1/clusterroles/klusterlet,v1/serviceaccounts/open-cluster-management-agent/klusterlet,scheduling.k8s.io/v1/priorityclasses/klusterlet-critical,rbac.authorization.k8s.io/v1/clusterroles/open-cluster-management:klusterlet-admin-aggregate-clusterrole,rbac.authorization.k8s.io/v1/clusterrolebindings/klusterlet,operator.open-cluster-management.io/v1/klusterlets/klusterlet,apiextensions.k8s.io/v1/customresourcedefinitions/klusterlets.operator.open-cluster-management.io,v1/secrets/open-cluster-management-agent/open-cluster-management-image-pull-credentials" labels: velero.io/storage-location: default namespace: openshift-adp spec: includedNamespaces: - open-cluster-management-agent includedClusterScopedResources: - klusterlets.operator.open-cluster-management.io - clusterroles.rbac.authorization.k8s.io - clusterrolebindings.rbac.authorization.k8s.io - priorityclasses.scheduling.k8s.io includedNamespaceScopedResources: - deployments - serviceaccounts - secrets excludedNamespaceScopedResources: [] --- apiVersion: velero.io/v1 kind: Restore metadata: name: acm-klusterlet namespace: openshift-adp labels: velero.io/storage-location: default annotations: lca.openshift.io/apply-wave: "1" spec: backupName: acm-klusterlet ``` > [!NOTE] > If your `multiclusterHub` CR does not have `.spec.imagePullSecret` defined and the secret does not exist on the `open-cluster-management-agent` namespace in your hub cluster, remove `v1/secrets/open-cluster-management-agent/open-cluster-management-image-pull-credentials` from the `lca.openshift.io/apply-label` annotation. 2. If you created persistent volumes on your cluster through LVM Storage, add the following `PlatformBackupRestoreLvms.yaml` file for LVM Storage artifacts: ```yaml apiVersion: velero.io/v1 kind: Backup metadata: labels: velero.io/storage-location: default name: lvmcluster namespace: openshift-adp spec: includedNamespaces: - openshift-storage includedNamespaceScopedResources: - lvmclusters - lvmvolumegroups - lvmvolumegroupnodestatuses --- apiVersion: velero.io/v1 kind: Restore metadata: name: lvmcluster namespace: openshift-adp labels: velero.io/storage-location: default annotations: lca.openshift.io/apply-wave: "2" spec: backupName: lvmcluster ``` - The `lca.openshift.io/apply-wave` value must be lower than the values specified in the application `Restore` CRs. 2. If you need to restore applications after the upgrade, create the OADP `Backup` and `Restore` CRs for your application in the `openshift-adp` namespace. 1. Create the OADP CRs for cluster-scoped application artifacts in the `openshift-adp` namespace, for example: ```yaml apiVersion: velero.io/v1 kind: Backup metadata: annotations: lca.openshift.io/apply-label: "apiextensions.k8s.io/v1/customresourcedefinitions/test.example.com,security.openshift.io/v1/securitycontextconstraints/test,rbac.authorization.k8s.io/v1/clusterroles/test-role,rbac.authorization.k8s.io/v1/clusterrolebindings/system:openshift:scc:test" name: backup-app-cluster-resources labels: velero.io/storage-location: default namespace: openshift-adp spec: includedClusterScopedResources: - customresourcedefinitions - securitycontextconstraints - clusterrolebindings - clusterroles excludedClusterScopedResources: - Namespace --- apiVersion: velero.io/v1 kind: Restore metadata: name: test-app-cluster-resources namespace: openshift-adp labels: velero.io/storage-location: default annotations: lca.openshift.io/apply-wave: "3" spec: backupName: backup-app-cluster-resources ``` - Replace the example resource names in the `lca.openshift.io/apply-label` field with your actual resources. - The value in the `lca.openshift.io/apply-wave` field must be higher than the value in the platform `Restore` CRs and lower than the value in the application namespace-scoped `Restore` CR. 2. Create the OADP CRs for your namespace-scoped application artifacts. When using LSO, see the following example OADP CRs: ```yaml apiVersion: velero.io/v1 kind: Backup metadata: labels: velero.io/storage-location: default name: backup-app namespace: openshift-adp spec: includedNamespaces: - test includedNamespaceScopedResources: - secrets - persistentvolumeclaims - deployments - statefulsets - configmaps - cronjobs - services - job - poddisruptionbudgets - excludedClusterScopedResources: - persistentVolumes --- apiVersion: velero.io/v1 kind: Restore metadata: name: test-app namespace: openshift-adp labels: velero.io/storage-location: default annotations: lca.openshift.io/apply-wave: "4" spec: backupName: backup-app ``` - Define custom resources for your application in the `includedNamespaceScopedResources` field. When using LVM Storage, see the following example OADP CRs: ```yaml apiVersion: velero.io/v1 kind: Backup metadata: labels: velero.io/storage-location: default name: backup-app namespace: openshift-adp spec: includedNamespaces: - test includedNamespaceScopedResources: - secrets - persistentvolumeclaims - deployments - statefulsets - configmaps - cronjobs - services - job - poddisruptionbudgets - includedClusterScopedResources: - persistentVolumes - logicalvolumes.topolvm.io - volumesnapshotcontents --- apiVersion: velero.io/v1 kind: Restore metadata: name: test-app namespace: openshift-adp labels: velero.io/storage-location: default annotations: lca.openshift.io/apply-wave: "4" spec: backupName: backup-app restorePVs: true restoreStatus: includedResources: - logicalvolumes ``` where: - ``: Define custom resources for your application. - `persistentVolumes`: Required field. - `logicalvolumes.topolvm.io`: Required field. - `volumesnapshotcontents`: Optional if you use LVM Storage volume snapshots. - `restoreStatus.includedResources`: Required field for restoring logical volumes. > [!IMPORTANT] > The same version of the applications must function on both the current and the target release of OpenShift Container Platform. 3. Create the `ConfigMap` object for your OADP CRs by running the following command: ```terminal $ oc create configmap oadp-cm-example --from-file=example-oadp-resources.yaml= -n openshift-adp ``` 4. Patch the `ImageBasedUpgrade` CR by running the following command: ```terminal $ oc patch imagebasedupgrades.lca.openshift.io upgrade \ -p='{"spec": {"oadpContent": [{"name": "oadp-cm-example", "namespace": "openshift-adp"}]}}' \ --type=merge -n openshift-lifecycle-agent ``` **Additional resources** {._additional-resources} - [Configuring a shared container partition between ostree stateroots](/openshift-docs-markdown/edge_computing/image_based_upgrade/preparing_for_image_based_upgrade/cnf-image-based-upgrade-shared-container-partition#cnf-image-based-upgrade-shared-container-partition_shared-container-partition) - [About installing OADP](/openshift-docs-markdown/backup_and_restore/application_backup_and_restore/installing/about-installing-oadp#about-installing-oadp) ## Creating ConfigMap objects of extra manifests for the image-based upgrade with Lifecycle Agent {#cnf-image-based-upgrade-prep-extramanifests_cnf-non-gitops} Create additional manifests that you want to apply to the target cluster. > [!NOTE] > If you add more than one extra manifest, and the manifests must be applied in a specific order, you must prefix the filenames of the manifests with numbers that represent the required order. For example, `00-namespace.yaml`, `01-sriov-extra-manifest.yaml`, and so on. **Procedure** 1. Create a YAML file that contains your extra manifests, such as SR-IOV. ```yaml {title="Example SR-IOV resources"} apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: "example-sriov-node-policy" namespace: openshift-sriov-network-operator spec: deviceType: vfio-pci isRdma: false nicSelector: pfNames: [ens1f0] nodeSelector: node-role.kubernetes.io/master: "" mtu: 1500 numVfs: 8 priority: 99 resourceName: example-sriov-node-policy --- apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: "example-sriov-network" namespace: openshift-sriov-network-operator spec: ipam: |- { } linkState: auto networkNamespace: sriov-namespace resourceName: example-sriov-node-policy spoofChk: "on" trust: "off" ``` 2. Create the `ConfigMap` object by running the following command: ```terminal $ oc create configmap example-extra-manifests-cm --from-file=example-extra-manifests.yaml= -n openshift-lifecycle-agent ``` 3. Patch the `ImageBasedUpgrade` CR by running the following command: ```terminal $ oc patch imagebasedupgrades.lca.openshift.io upgrade \ -p='{"spec": {"extraManifests": [{"name": "example-extra-manifests-cm", "namespace": "openshift-lifecycle-agent"}]}}' \ --type=merge -n openshift-lifecycle-agent ``` ## Creating ConfigMap objects of custom catalog sources for the image-based upgrade with Lifecycle Agent {#cnf-image-based-upgrade-prep-catalogsources_cnf-non-gitops} You can keep your custom catalog sources after the upgrade by generating a `ConfigMap` object for your catalog sources and adding them to the `spec.extraManifest` field in the `ImageBasedUpgrade` CR. For more information about catalog sources, see "Catalog source". **Procedure** 1. Create a YAML file that contains the `CatalogSource` CR: ```yaml apiVersion: operators.coreos.com/v1 kind: CatalogSource metadata: name: example-catalogsources namespace: openshift-marketplace spec: sourceType: grpc displayName: disconnected-redhat-operators image: quay.io/example-org/example-catalog:v1 ``` 2. Create the `ConfigMap` object by running the following command: ```terminal $ oc create configmap example-catalogsources-cm --from-file=example-catalogsources.yaml= -n openshift-lifecycle-agent ``` 3. Patch the `ImageBasedUpgrade` CR by running the following command: ```terminal $ oc patch imagebasedupgrades.lca.openshift.io upgrade \ -p='{"spec": {"extraManifests": [{"name": "example-catalogsources-cm", "namespace": "openshift-lifecycle-agent"}]}}' \ --type=merge -n openshift-lifecycle-agent ``` **Additional resources** {._additional-resources} - [Catalog source](/openshift-docs-markdown/operators/understanding/olm/olm-understanding-olm#olm-catalogsource_olm-understanding-olm) - [Performing an image-based upgrade for single-node OpenShift with Lifecycle Agent](/openshift-docs-markdown/edge_computing/image_based_upgrade/cnf-image-based-upgrade-base#cnf-image-based-upgrade)