1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/cnf-image-based-upgrade-prep.adoc

133 lines
5.0 KiB
Plaintext

// Module included in the following assemblies:
// * edge_computing/image-based-upgrade/cnf-image-based-upgrade-base.adoc
:_mod-docs-content-type: PROCEDURE
[id="ztp-image-based-upgrade-prep_{context}"]
= Moving to the Prep stage of the image-based upgrade with {lcao}
When you deploy the {lcao} on a cluster, an `ImageBasedUpgrade` custom resource (CR) is automatically created.
After you created all the resources that you need during the upgrade, you can move on to the `Prep` stage.
For more information, see the "Creating ConfigMap objects for the image-based upgrade with {lcao}" section.
[NOTE]
====
In a disconnected environment, if the seed cluster's release image registry is different from the target cluster's release image registry, you must create an `ImageDigestMirrorSet` (IDMS) resource to configure alternative mirrored repository locations. For more information, see "Configuring image registry repository mirroring".
You can retrieve the release registry used in the seed image by running the following command:
[source,terminal]
----
$ skopeo inspect docker://<imagename> | jq -r '.Labels."com.openshift.lifecycle-agent.seed_cluster_info" | fromjson | .release_registry'
----
====
.Prerequisites
* You have created resources to back up and restore your clusters.
.Procedure
. Check that you have patched your `ImageBasedUpgrade` CR:
+
[source,yaml]
----
apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
name: upgrade
spec:
stage: Idle
seedImageRef:
version: 4.15.2 # <1>
image: <seed_container_image> # <2>
pullSecretRef: <seed_pull_secret> # <3>
autoRollbackOnFailure: {}
# initMonitorTimeoutSeconds: 1800 # <4>
extraManifests: # <5>
- name: example-extra-manifests-cm
namespace: openshift-lifecycle-agent
- name: example-catalogsources-cm
namespace: openshift-lifecycle-agent
oadpContent: # <6>
- name: oadp-cm-example
namespace: openshift-adp
----
<1> Target platform version. The value must match the version of the seed image.
<2> Repository where the target cluster can pull the seed image from.
<3> Reference to a secret with credentials to pull container images if the images are in a private registry.
<4> Optional: Time frame in seconds to roll back if the upgrade does not complete within that time frame after the first reboot. If not defined or set to `0`, the default value of `1800` seconds (30 minutes) is used.
<5> Optional: List of `ConfigMap` resources that contain your custom catalog sources to retain after the upgrade and your extra manifests to apply to the target cluster that are not part of the seed image.
<6> List of `ConfigMap` resources that contain the {oadp-short} `Backup` and `Restore` CRs.
. To start the `Prep` stage, change the value of the `stage` field to `Prep` in the `ImageBasedUpgrade` CR by running the following command:
+
--
[source,terminal]
----
$ oc patch imagebasedupgrades.lca.openshift.io upgrade -p='{"spec": {"stage": "Prep"}}' --type=merge -n openshift-lifecycle-agent
----
If you provide `ConfigMap` objects for {oadp-short} resources and extra manifests, {lcao} validates the specified `ConfigMap` objects during the `Prep` stage.
You might encounter the following issues:
* Validation warnings or errors if the {lcao} detects any issues with the `extraManifests` parameters.
* Validation errors if the {lcao} detects any issues with the `oadpContent` parameters.
Validation warnings do not block the `Upgrade` stage but you must decide if it is safe to proceed with the upgrade.
These warnings, for example missing CRDs, namespaces, or dry run failures, update the `status.conditions` for the `Prep` stage and `annotation` fields in the `ImageBasedUpgrade` CR with details about the warning.
.Example validation warning
[source,yaml]
----
# ...
metadata:
annotations:
extra-manifest.lca.openshift.io/validation-warning: '...'
# ...
----
However, validation errors, such as adding `MachineConfig` or Operator manifests to extra manifests, cause the `Prep` stage to fail and block the `Upgrade` stage.
When the validations pass, the cluster creates a new `ostree` stateroot, which involves pulling and unpacking the seed image, and running host-level commands.
Finally, all the required images are precached on the target cluster.
--
.Verification
* Check the status of the `ImageBasedUpgrade` CR by running the following command:
+
--
[source,terminal]
----
$ oc get ibu -o yaml
----
.Example output
[source,yaml]
----
conditions:
- lastTransitionTime: "2024-01-01T09:00:00Z"
message: In progress
observedGeneration: 13
reason: InProgress
status: "False"
type: Idle
- lastTransitionTime: "2024-01-01T09:00:00Z"
message: Prep completed
observedGeneration: 13
reason: Completed
status: "False"
type: PrepInProgress
- lastTransitionTime: "2024-01-01T09:00:00Z"
message: Prep stage completed successfully
observedGeneration: 13
reason: Completed
status: "True"
type: PrepCompleted
observedGeneration: 13
validNextStages:
- Idle
- Upgrade
----
--