Skip to content

Commit

Permalink
TELCODOCS-1861: Add Lifecycle Agent Enhancements 4.17
Browse files Browse the repository at this point in the history
  • Loading branch information
amolnar-rh committed Jan 8, 2025
1 parent 4e93433 commit 148be11
Show file tree
Hide file tree
Showing 12 changed files with 552 additions and 80 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -78,10 +78,6 @@ include::modules/cnf-image-based-upgrade.adoc[leveloffset=+1]
* xref:../../edge_computing/image_based_upgrade/ztp-image-based-upgrade.adoc#ztp-image-based-upgrade[Performing an image-based upgrade for {sno} clusters using {ztp}]
* xref:../../edge_computing/image_based_upgrade/cnf-image-based-upgrade-base.adoc#cnf-image-based-upgrade-rollback_cnf-non-gitops[Moving to the Rollback stage of the image-based upgrade with {lcao}]
* xref:../../edge_computing/image_based_upgrade/ztp-image-based-upgrade.adoc#ztp-image-based-upgrade-rollback_ztp-gitops[Moving to the Rollback stage of the image-based upgrade with {lcao} and {ztp}]
include::modules/cnf-image-based-upgrade-guidelines.adoc[leveloffset=+1]

[role="_additional-resources"]
Expand Down
35 changes: 22 additions & 13 deletions edge_computing/image_based_upgrade/ztp-image-based-upgrade.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -6,44 +6,53 @@ include::_attributes/common-attributes.adoc[]

toc::[]

You can upgrade your managed {sno} cluster with the image-based upgrade through {ztp-first}.

When you deploy the {lcao} on a cluster, an `ImageBasedUpgrade` CR is automatically created.
You update this CR to specify the image repository of the seed image and to move through the different stages.

// Lifecycle Agent (LCA)

include::modules/ztp-image-based-upgrade-prep.adoc[leveloffset=+1]
You can use a single resource on the hub cluster, the `ImageBasedGroupUpgrade` custom resource (CR), to manage an imaged-based upgrade on a selected group of managed clusters through all stages.
{cgu-operator-first} reconciles the `ImageBasedGroupUpgrade` CR and creates the underlying resources to complete the defined stage transitions, either in a manually controlled or a fully automated upgrade flow.

For more information about the image-based upgrade, see "Understanding the image-based upgrade for single-node OpenShift clusters".

[role="_additional-resources"]
.Additional resources

* xref:../../edge_computing/ztp-preparing-the-hub-cluster.adoc#ztp-preparing-the-ztp-git-repository-ver-ind_ztp-preparing-the-hub-cluster[Preparing the {ztp} site configuration repository for version independence]
* xref:../../edge_computing/image_based_upgrade/cnf-understanding-image-based-upgrade.adoc#cnf-understanding-image-based-upgrade[Understanding the image-based upgrade for single-node OpenShift clusters]
* xref:../../edge_computing/image_based_upgrade/preparing_for_image_based_upgrade/ztp-image-based-upgrade-prep-resources.adoc#ztp-image-based-upgrade-prep-resources[Creating ConfigMap objects for the image-based upgrade with {lcao} using {ztp}]
include::modules/ztp-image-based-upgrade-concept.adoc[leveloffset=+1]

include::modules/ztp-image-based-upgrade-procedure-steps.adoc[leveloffset=+1]

[role="_additional-resources"]
.Additional resources

* xref:../../edge_computing/image_based_upgrade/preparing_for_image_based_upgrade/cnf-image-based-upgrade-shared-container-partition.adoc#ztp-image-based-upgrade-shared-container-partition_shared-container-partition[Configuring a shared container partition between ostree stateroots when using {ztp}]
* xref:../../edge_computing/image_based_upgrade/preparing_for_image_based_upgrade/ztp-image-based-upgrade-prep-resources.adoc#ztp-image-based-upgrade-prep-resources[Creating ConfigMap objects for the image-based upgrade with {lcao} using {ztp}]
* xref:../../backup_and_restore/application_backup_and_restore/installing/installing-oadp-ocs.adoc#oadp-about-backup-snapshot-locations_installing-oadp-ocs[About backup and snapshot locations and their secrets]
* xref:../../backup_and_restore/application_backup_and_restore/backing_up_and_restoring/oadp-creating-backup-cr.adoc#oadp-creating-backup-cr-doc[Creating a Backup CR]
* xref:../../backup_and_restore/application_backup_and_restore/backing_up_and_restoring/restoring-applications.adoc#oadp-creating-restore-cr_restoring-applications[Creating a Restore CR]
include::modules/ztp-image-based-upgrade-upgrade.adoc[leveloffset=+1]
* xref:../../edge_computing/image_based_upgrade/ztp-image-based-upgrade.adoc#ztp-image-based-upgrade-supported-combinations_ztp-gitops[Supported action combinations]
include::modules/ztp-image-based-upgrade-procedure-one-step.adoc[leveloffset=+1]

include::modules/ztp-image-based-upgrade-procedure-cancel.adoc[leveloffset=+1]

[role="_additional-resources"]
.Additional resources

* xref:../../edge_computing/image_based_upgrade/ztp-image-based-upgrade.adoc#ztp-image-based-upgrade-rollback_ztp-gitops[Moving to the Rollback stage of the image-based upgrade with {lcao} and {ztp}]
* xref:../../edge_computing/cnf-talm-for-cluster-upgrades.adoc#talo-policies-concept_cnf-topology-aware-lifecycle-manager[Update policies on managed clusters]
* xref:../../edge_computing/image_based_upgrade/ztp-image-based-upgrade.adoc#ztp-image-based-upgrade-supported-combinations_ztp-gitops[Supported action combinations]
include::modules/ztp-image-based-upgrade-rollback.adoc[leveloffset=+1]
include::modules/ztp-image-based-upgrade-procedure-rollback.adoc[leveloffset=+1]

[role="_additional-resources"]
.Additional resources

* xref:../../edge_computing/image_based_upgrade/ztp-image-based-upgrade.adoc#ztp-image-based-upgrade-supported-combinations_ztp-gitops[Supported action combinations]
* xref:../../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-3-expired-certs.adoc#dr-scenario-3-recovering-expired-certs_dr-recovering-expired-certs[Recovering from expired control plane certificates]
include::modules/cnf-image-based-upgrade-troubleshooting.adoc[leveloffset=+1]
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ Label your extra manifests so that the {lcao} can extract resources that are lab
.Procedure

. Label your required extra manifests with the `lca.openshift.io/target-ocp-version: <target_version>` label in your existing `PolicyGenTemplate` CR:
. Label your required extra manifests with the `lca.openshift.io/target-ocp-version: <target_version>` label in your existing site `PolicyGenTemplate` CR:
+
[source,yaml]
----
Expand Down
72 changes: 16 additions & 56 deletions modules/ztp-image-based-upgrade-prep-oadp.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
// * edge_computing/image-based-upgrade/cnf-preparing-for-image-based-upgrade.adoc

:_mod-docs-content-type: PROCEDURE
[id="zztp-image-based-upgrade-prep-oadp_{context}"]
[id="ztp-image-based-upgrade-prep-oadp_{context}"]
= Creating {oadp-short} resources for the image-based upgrade with {ztp}

Prepare your {oadp-short} resources to restore your application after an upgrade.
Expand All @@ -16,6 +16,7 @@ Prepare your {oadp-short} resources to restore your application after an upgrade
* Deploy a version of {lcao} that is compatible with the version used with the seed image.
* Install the {oadp-short} Operator, the `DataProtectionApplication` CR, and its secret on the target cluster.
* Create an S3-compatible storage solution and a ready-to-use bucket with proper credentials configured. For more information, see "Installing and configuring the {oadp-short} Operator with {ztp}".
* The `openshift-adp` namespace for the OADP `ConfigMap` object must exist on all managed clusters and the hub for the OADP `ConfigMap` to be generated and copied to the clusters.
.Procedure

Expand All @@ -29,20 +30,20 @@ Prepare your {oadp-short} resources to restore your application after an upgrade
│ │ ├── ImageBasedUpgrade.yaml
│ │ ├── PlatformBackupRestore.yaml
│ │ ├── PlatformBackupRestoreLvms.yaml
│ │ ├── PlatformBackupRestoreWithIBGU.yaml
├── ...
├── ibu-upgrade-ranGen.yaml
├── kustomization.yaml
----

[IMPORTANT]
====
The `kustomization.yaml` file must be located in the same directory structure as previously shown to reference the `ibu-upgrade-ranGen.yaml` manifest.
====
The `source-crs/ibu/PlatformBackupRestoreWithIBGU.yaml` file is provided in the ZTP container image.

The `source-crs/ibu/PlatformBackupRestore.yaml` file is provided in the ZTP container image.
.PlatformBackupRestoreWithIBGU.yaml
include::snippets/ibu-PlatformBackupRestoreWithIBGU.adoc[]

.PlatformBackupRestore.yaml
include::snippets/ibu-PlatformBackupRestore.adoc[]
[NOTE]
====
If you perform the image-based upgrade directly on managed clusters, use the `PlatformBackupRestore.yaml` file.
====

If you use {lvms} to create persistent volumes, you can use the `source-crs/ibu/PlatformBackupRestoreLvms.yaml` provided in the ZTP container image to back up your {lvms} resources.

Expand Down Expand Up @@ -72,65 +73,24 @@ The same version of the applications must function on both the current and the t
====
--

. Create the `oadp-cm` `ConfigMap` object through the `oadp-cm-policy` in a new `PolicyGenTemplate` called `ibu-upgrade-ranGen.yaml`:
+
[source,yaml]
----
apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
name: example-group-ibu
namespace: "ztp-group"
spec:
bindingRules:
group-du-sno: ""
mcp: "master"
evaluationInterval:
compliant: 10s
noncompliant: 10s
sourceFiles:
- fileName: ConfigMapGeneric.yaml
complianceType: mustonlyhave
policyName: "oadp-cm-policy"
metadata:
name: oadp-cm
namespace: openshift-adp
----

. Create a `kustomization.yaml` with the following content:
+
[source,yaml]
----
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

generators: <1>
- ibu-upgrade-ranGen.yaml

configMapGenerator: <2>
configMapGenerator: # <1>
- files:
- source-crs/ibu/PlatformBackupRestore.yaml
- source-crs/ibu/PlatformBackupRestoreWithIBGU.yaml
#- source-crs/custom-crs/ApplicationClusterScopedBackupRestore.yaml
#- source-crs/custom-crs/ApplicationApplicationBackupRestoreLso.yaml
name: oadp-cm
namespace: ztp-group
namespace: openshift-adp # <2>
generatorOptions:
disableNameSuffixHash: true


patches: <3>
- target:
group: policy.open-cluster-management.io
version: v1
kind: Policy
name: example-group-ibu-oadp-cm-policy
patch: |-
- op: replace
path: /spec/policy-templates/0/objectDefinition/spec/object-templates/0/objectDefinition/data
value: '{{hub copyConfigMapData "ztp-group" "oadp-cm" hub}}'
disableNameSuffixHash: true
----
<1> Generates the `oadp-cm-policy`.
<2> Creates the `oadp-cm` `ConfigMap` object on the hub cluster with `Backup` and `Restore` CRs.
<3> Overrides the data field of `ConfigMap` added in `oadp-cm-policy`. A hub template is used to propagate the `oadp-cm` `ConfigMap` to all target clusters.
<1> Creates the `oadp-cm` `ConfigMap` object on the hub cluster with `Backup` and `Restore` CRs.
<2> The namespace must exist on all managed clusters and the hub for the OADP `ConfigMap` to be generated and copied to the clusters.

. Push the changes to your Git repository.
84 changes: 84 additions & 0 deletions modules/ztp-image-based-upgrade-procedure-cancel.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
// Module included in the following assemblies:
// * edge_computing/image-based-upgrade/ztp-image-based-upgrade.adoc

:_mod-docs-content-type: CONCEPT
[id="ztp-image-based-upgrade-procedure-cancel_{context}"]
= Canceling an image-based upgrade on managed clusters at scale

You can cancel the upgrade on a set of managed clusters that completed the `Prep` stage.

include::snippets/ibu-supported-action-combinations.adoc[]

.Prerequisites

* You have logged in to the hub cluster as a user with `cluster-admin` privileges.
.Procedure

. Create a separate YAML file on the hub cluster that contains the `ImageBasedGroupUpgrade` CR:
+
[source,yaml]
----
apiVersion: lcm.openshift.io/v1alpha1
kind: ImageBasedGroupUpgrade
metadata:
name: <filename>
namespace: default
spec:
clusterLabelSelectors:
- matchExpressions:
- key: name
operator: In
values:
- spoke4
ibuSpec:
seedImageRef:
image: quay.io/seed/image:4.16.0-rc.1
version: 4.16.0-rc.1
pullSecretRef:
name: "<seed_pull_secret>"
extraManifests:
- name: example-extra-manifests
namespace: openshift-lifecycle-agent
oadpContent:
- name: oadp-cm
namespace: openshift-adp
plan:
- actions: ["Abort"]
rolloutStrategy:
maxConcurrency: 5
timeout: 10
----
+
All managed clusters that completed the `Prep` stage are moved back to the `Idle` stage.

. Apply the created file by running the following command on the hub cluster:
+
[source,terminal]
----
$ oc apply -f <filename>.yaml
----

.Verification

* Monitor the status updates by running the following command:
+
[source,terminal]
----
$ oc get ibgu -o yaml
----
+
.Example output
[source,yaml]
----
# ...
status:
clusters:
- completedActions:
- action: Prep
currentActions:
- action: Abort
name: spoke4
# ...
----
63 changes: 63 additions & 0 deletions modules/ztp-image-based-upgrade-procedure-one-step.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
// Module included in the following assemblies:
// * edge_computing/image-based-upgrade/ztp-image-based-upgrade.adoc

:_mod-docs-content-type: CONCEPT
[id="ztp-image-based-upgrade-procedure-one-step_{context}"]
= Performing an image-based upgrade on managed clusters at scale in one step

For use cases when service interruption is not a concern, you can upgrade a set of your managed clusters by using the `ImageBasedGroupUpgrade` CR with several actions combined in one step with one rollout strategy.
With one rollout strategy, the upgrade time can be reduced but you can only troubleshoot failed clusters after the upgrade plan is complete.

.Prerequisites

* You have logged in to the hub cluster as a user with `cluster-admin` privileges.
* You have created policies and `ConfigMap` objects for resources used in the image-based upgrade.
* You have installed the {lcao} and OADP Operators on all managed clusters through the hub cluster.
.Procedure

. Create a YAML file on the hub cluster that contains the `ImageBasedGroupUpgrade` CR:
+
--
include::snippets/ibu-ImageBasedGroupUpgrade.adoc[]
--

. Apply the created file by running the following command on the hub cluster:
+
[source,terminal]
----
$ oc apply -f <filename>.yaml
----

.Verification

* Monitor the status updates by running the following command:
+
--
[source,terminal]
----
$ oc get ibgu -o yaml
----
.Example output
[source,yaml]
----
# ...
status:
clusters:
- completedActions:
- action: Prep
failedActions:
- action: Upgrade
name: spoke1
- completedActions:
- action: Prep
- action: Upgrade
- action: FinalizeUpgrade
name: spoke4
- failedActions:
- action: Prep
name: spoke6
# ...
----
--
Loading

0 comments on commit 148be11

Please sign in to comment.