mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
143 lines
5.6 KiB
Plaintext
143 lines
5.6 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * scalability_and_performance/ztp_far_edge/ztp-preparing-the-hub-cluster.adoc
|
|
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="ztp-preparing-the-ztp-git-repository-ver-ind_{context}"]
|
|
= Preparing the {ztp} site configuration repository for version independence
|
|
|
|
You can use {ztp} to manage source custom resources (CRs) for managed clusters that are running different versions of {product-title}.
|
|
This means that the version of {product-title} running on the hub cluster can be independent of the version running on the managed clusters.
|
|
|
|
[NOTE]
|
|
====
|
|
The following procedure assumes you are using `PolicyGenerator` resources instead of `PolicyGentemplate` resources for cluster policies management.
|
|
====
|
|
|
|
.Prerequisites
|
|
|
|
* You have installed the OpenShift CLI (`oc`).
|
|
|
|
* You have logged in as a user with `cluster-admin` privileges.
|
|
|
|
.Procedure
|
|
|
|
. Create a directory structure with separate paths for the `ClusterInstance` and `PolicyGenerator` CRs.
|
|
|
|
. Within the `PolicyGenerator` directory, create a directory for each {product-title} version you want to make available.
|
|
For each version, create the following resources:
|
|
* `kustomization.yaml` file that explicitly includes the files in that directory
|
|
* `source-crs` directory to contain reference CR configuration files from the `ztp-site-generate` container
|
|
+
|
|
If you want to work with user-provided CRs, you must create a separate directory for them.
|
|
|
|
. In the `/clusterinstance` directory, create a subdirectory for each {product-title} version you want to make available. For each version, create at least one directory for reference CRs to be copied from the container. There is no restriction on the naming of directories or on the number of reference directories. If you want to work with custom manifests, you must create a separate directory for them.
|
|
+
|
|
The following example describes a structure using user-provided manifests and CRs for different versions of {product-title}:
|
|
+
|
|
[source,text]
|
|
----
|
|
├── acmpolicygenerator
|
|
│ ├── kustomization.yaml <1>
|
|
│ ├── version_4.13 <2>
|
|
│ │ ├── common-ranGen.yaml
|
|
│ │ ├── group-du-sno-ranGen.yaml
|
|
│ │ ├── group-du-sno-validator-ranGen.yaml
|
|
│ │ ├── helix56-v413.yaml
|
|
│ │ ├── kustomization.yaml <3>
|
|
│ │ ├── ns.yaml
|
|
│ │ └── source-crs/ <4>
|
|
│ │ └── reference-crs/ <5>
|
|
│ │ └── custom-crs/ <6>
|
|
│ └── version_4.14 <2>
|
|
│ ├── common-ranGen.yaml
|
|
│ ├── group-du-sno-ranGen.yaml
|
|
│ ├── group-du-sno-validator-ranGen.yaml
|
|
│ ├── helix56-v414.yaml
|
|
│ ├── kustomization.yaml <3>
|
|
│ ├── ns.yaml
|
|
│ └── source-crs/ <4>
|
|
│ └── reference-crs/ <5>
|
|
│ └── custom-crs/ <6>
|
|
└── clusterinstance
|
|
├── kustomization.yaml
|
|
├── version_4.13
|
|
│ ├── helix56-v413.yaml
|
|
│ ├── kustomization.yaml
|
|
│ ├── extra-manifest/ <7>
|
|
│ └── custom-manifest/ <8>
|
|
└── version_4.14
|
|
├── helix57-v414.yaml
|
|
├── kustomization.yaml
|
|
├── extra-manifest/
|
|
└── custom-manifest/
|
|
|
|
----
|
|
<1> Create a top-level `kustomization` YAML file.
|
|
<2> Create the version-specific directories within the custom `/acmpolicygenerator` directory.
|
|
<3> Create a `kustomization.yaml` file for each version.
|
|
<4> Create a `source-crs` directory for each version to contain reference CRs from the `ztp-site-generate` container.
|
|
<5> Create the `reference-crs` directory for policy CRs that are extracted from the ZTP container.
|
|
<6> Optional: Create a `custom-crs` directory for user-provided CRs.
|
|
<7> Create a directory within the custom `/clusterinstance` directory to contain extra manifests from the `ztp-site-generate` container.
|
|
<8> Create a folder to hold user-provided manifests.
|
|
+
|
|
[NOTE]
|
|
====
|
|
In the example directory structure, each version subdirectory in the custom `/clusterinstance` directory contains two further subdirectories, one containing the reference manifests copied from the container, the other for custom manifests that you provide.
|
|
The names assigned to those directories are examples.
|
|
====
|
|
|
|
. Create ConfigMaps from the manifest directories and reference them in the `ClusterInstance` CR using the `extraManifestsRefs` field.
|
|
+
|
|
.Example kustomization.yaml with configMapGenerator
|
|
+
|
|
[source,yaml]
|
|
----
|
|
apiVersion: kustomize.config.k8s.io/v1beta1
|
|
kind: Kustomization
|
|
|
|
configMapGenerator:
|
|
- name: extra-manifests-cm
|
|
namespace: helix56-v413
|
|
files:
|
|
- extra-manifest/workload-partitioning.yaml <1>
|
|
- extra-manifest/enable-crun-master.yaml
|
|
- custom-manifest/custom-config.yaml <2>
|
|
# ...
|
|
|
|
generatorOptions:
|
|
disableNameSuffixHash: true
|
|
----
|
|
<1> Extra manifest files from the `ztp-site-generate` container.
|
|
<2> User-provided custom manifest files.
|
|
|
|
. Edit the `ClusterInstance` CR to reference the `ConfigMap` CR:
|
|
+
|
|
.Example ClusterInstance CR
|
|
+
|
|
[source,yaml]
|
|
----
|
|
apiVersion: siteconfig.open-cluster-management.io/v1alpha1
|
|
kind: ClusterInstance
|
|
metadata:
|
|
name: helix56-v413
|
|
namespace: helix56-v413
|
|
spec:
|
|
# ...
|
|
extraManifestsRefs:
|
|
- name: extra-manifests-cm <1>
|
|
----
|
|
<1> Reference the ConfigMap containing the extra manifests.
|
|
|
|
. Edit the top-level `kustomization.yaml` file to control which {product-title} versions are active. The following is an example of a `kustomization.yaml` file at the top level:
|
|
+
|
|
[source,yaml]
|
|
----
|
|
resources:
|
|
- version_4.13 <1>
|
|
#- version_4.14 <2>
|
|
----
|
|
<1> Activate version 4.13.
|
|
<2> Use comments to deactivate a version.
|