Preparing the GitOps ZTP site configuration repository for version independence

You can use GitOps ZTP to manage source custom resources (CRs) for managed clusters that are running different versions of OpenShift Container Platform. This means that the version of OpenShift Container Platform 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
  1. Create a directory structure with separate paths for the ClusterInstance and PolicyGenerator CRs.

  2. Within the PolicyGenerator directory, create a directory for each OpenShift Container Platform 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.

  3. In the /clusterinstance directory, create a subdirectory for each OpenShift Container Platform 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 OpenShift Container Platform:

    ├── acmpolicygenerator
    │   ├── kustomization.yaml
    │   ├── version_4.13
    │   │   ├── common-ranGen.yaml
    │   │   ├── group-du-sno-ranGen.yaml
    │   │   ├── group-du-sno-validator-ranGen.yaml
    │   │   ├── helix56-v413.yaml
    │   │   ├── kustomization.yaml
    │   │   ├── ns.yaml
    │   │   └── source-crs/
    │   │      └── reference-crs/
    │   │      └── custom-crs/
    │   └── version_4.14
    │       ├── common-ranGen.yaml
    │       ├── group-du-sno-ranGen.yaml
    │       ├── group-du-sno-validator-ranGen.yaml
    │       ├── helix56-v414.yaml
    │       ├── kustomization.yaml
    │       ├── ns.yaml
    │       └── source-crs/
    │         └── reference-crs/
    │         └── custom-crs/
    └── clusterinstance
        ├── kustomization.yaml
        ├── version_4.13
        │   ├── helix56-v413.yaml
        │   ├── kustomization.yaml
        │   ├── extra-manifest/
        │   └── custom-manifest/
        └── version_4.14
            ├── helix57-v414.yaml
            ├── kustomization.yaml
            ├── extra-manifest/
            └── custom-manifest/

    where:

    kustomization.yaml (top-level)

    Create a top-level kustomization YAML file.

    version_4.13, version_4.14

    Create the version-specific directories within the custom /acmpolicygenerator directory.

    kustomization.yaml (per-version)

    Create a kustomization.yaml file for each version.

    source-crs/

    Create a source-crs directory for each version to contain reference CRs from the ztp-site-generate container.

    reference-crs/

    Create the reference-crs directory for policy CRs that are extracted from the ZTP container.

    custom-crs/

    Optional: Create a custom-crs directory for user-provided CRs.

    extra-manifest/

    Create a directory within the custom /clusterinstance directory to contain extra manifests from the ztp-site-generate container.

    custom-manifest/

    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.

  4. Create ConfigMaps from the manifest directories and reference them in the ClusterInstance CR using the extraManifestsRefs field.

    Example kustomization.yaml with configMapGenerator:

    apiVersion: kustomize.config.k8s.io/v1beta1
    kind: Kustomization
    
    configMapGenerator:
    - name: extra-manifests-cm
      namespace: helix56-v413
      files:
      - extra-manifest/workload-partitioning.yaml
      - extra-manifest/enable-crun-master.yaml
      - custom-manifest/custom-config.yaml
      # ...
    
    generatorOptions:
      disableNameSuffixHash: true

    where:

    extra-manifest/

    Extra manifest files from the ztp-site-generate container.

    custom-manifest/

    User-provided custom manifest files.

  5. Edit the ClusterInstance CR to reference the ConfigMap CR:

    Example ClusterInstance CR:

    apiVersion: siteconfig.open-cluster-management.io/v1alpha1
    kind: ClusterInstance
    metadata:
      name: helix56-v413
      namespace: helix56-v413
    spec:
      # ...
      extraManifestsRefs:
      - name: extra-manifests-cm

    The extra-manifests-cm value references the ConfigMap containing the extra manifests.

  6. Edit the top-level kustomization.yaml file to control which OpenShift Container Platform versions are active. The following is an example of a kustomization.yaml file at the top level:

    resources:
    - version_4.13
    #- version_4.14

    where:

    version_4.13

    Activate version 4.13.

    #- version_4.14

    Use comments to deactivate a version.