Edge computing

Procedure

1. Log in to the mirror host.

2. Obtain the RHCOS ISO and RootFS images from mirror.openshift.com, for example:

   1. Export the required image names and OpenShift Container Platform version as environment variables:

      $ export ISO_IMAGE_NAME=<iso_image_name> 

      1

      $ export ROOTFS_IMAGE_NAME=<rootfs_image_name> 

      1

      $ export OCP_VERSION=<ocp_version> 

      1

      1

      ISO image name, for example, rhcos-4.20.1-x86_64-live.x86_64.iso

      1

      RootFS image name, for example, rhcos-4.20.1-x86_64-live-rootfs.x86_64.img

      1

      OpenShift Container Platform version, for example, 4.20.1

   2. Download the required images:

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.20/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.20/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}

Procedure

1. Enable the

   Provisioning

   resource to watch all namespaces and configure mirrors for disconnected environments. For more information, see Enabling the central infrastructure management service.

2. Open the

   AgentServiceConfig

   CR to update the

   spec.osImages

   field by running the following command:

   $ oc edit AgentServiceConfig

3. Update the

   spec.osImages

   field in the

   AgentServiceConfig

   CR:

   apiVersion: agent-install.openshift.io/v1beta1
   kind: AgentServiceConfig
   metadata:
    name: agent
   spec:
   # ...
     osImages:
       - cpuArchitecture: x86_64
         openshiftVersion: "4.20"
         rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
         url: https://<host>/<path>/rhcos-live.x86_64.iso

   where:

   <host>

   Specifies the fully qualified domain name (FQDN) for the target mirror registry HTTP server.

   <path>

   Specifies the path to the image on the target mirror registry.

4. Save and quit the editor to apply the changes.

Procedure

1. Create a

   ConfigMap

   containing the mirror registry config:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: assisted-installer-mirror-config
     namespace: multicluster-engine 

   1

   
     labels:
       app: assisted-service
   data:
     ca-bundle.crt: | 

   2

   
       -----BEGIN CERTIFICATE-----
       <certificate_contents>
       -----END CERTIFICATE-----
   
     registries.conf: | 

   3

   
       unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
   
       [[registry]]
          prefix = ""
          location = "quay.io/example-repository" 

   4

   
          mirror-by-digest-only = true
   
          [[registry.mirror]]
          location = "mirror1.registry.corp.com:5000/example-repository" 

   5

   1

   The ConfigMap namespace must be set to multicluster-engine.

   2

   The mirror registry’s certificate that is used when creating the mirror registry.

   3

   The configuration file for the mirror registry. The mirror registry configuration adds mirror information to the /etc/containers/registries.conf file in the discovery image. The mirror information is stored in the imageContentSources section of the install-config.yaml file when the information is passed to the installation program. The Assisted Service pod that runs on the hub cluster fetches the container images from the configured mirror registry.

   4

   The URL of the mirror registry. You must use the URL from the imageContentSources section by running the oc adm release mirror command when you configure the mirror registry. For more information, see the Mirroring the OpenShift Container Platform image repository section.

   5

   The registries defined in the registries.conf file must be scoped by repository, not by registry. In this example, both the quay.io/example-repository and the mirror1.registry.corp.com:5000/example-repository repositories are scoped by the example-repository repository.

   This updates

   mirrorRegistryRef

   in the

   AgentServiceConfig

   custom resource, as shown below:

   Example output

   apiVersion: agent-install.openshift.io/v1beta1
   kind: AgentServiceConfig
   metadata:
     name: agent
     namespace: multicluster-engine 

   1

   
   spec:
     databaseStorage:
       volumeName: <db_pv_name>
       accessModes:
       - ReadWriteOnce
       resources:
         requests:
           storage: <db_storage_size>
     filesystemStorage:
       volumeName: <fs_pv_name>
       accessModes:
       - ReadWriteOnce
       resources:
         requests:
           storage: <fs_storage_size>
     mirrorRegistryRef:
       name: assisted-installer-mirror-config 

   2

   
     osImages:
       - openshiftVersion: <ocp_version> 

   3

   
         url: <iso_url> 

   4

   1

   Set the AgentServiceConfig namespace to multicluster-engine to match the ConfigMap namespace.

   2

   Set mirrorRegistryRef.name to match the definition specified in the related ConfigMap CR.

   3

   Set the OpenShift Container Platform version to either the x.y or x.y.z format.

   4

   Set the URL for the ISO hosted on the httpd server.

Procedure

1. Update the

   AgentServiceConfig

   custom resource (CR) by running the following command:

   $ oc edit AgentServiceConfig agent

2. Add the

   unauthenticatedRegistries

   field in the CR:

   apiVersion: agent-install.openshift.io/v1beta1
   kind: AgentServiceConfig
   metadata:
     name: agent
   spec:
     unauthenticatedRegistries:
     - example.registry.com
     - example.registry2.com
     ...

   Unauthenticated registries are listed under

   spec.unauthenticatedRegistries

   in the

   AgentServiceConfig

   resource. Any registry on this list is not required to have an entry in the pull secret used for the spoke cluster installation.

   assisted-service

   validates the pull secret by making sure it contains the authentication information for every image registry used for installation.

1. Open a debug shell prompt to the hub cluster:

   $ oc debug node/<node_name>

2. Test access to the unauthenticated registry by running the following command:

   sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>

   where:

   <unauthenticated_registry>

   Is the new registry, for example, unauthenticated-image-registry.openshift-image-registry.svc:5000.

   Example output

   Login Succeeded!

Procedure

1. Prepare the ArgoCD pipeline configuration:

   1. Create a Git repository with the directory structure similar to the example directory. For more information, see "Preparing the GitOps ZTP site configuration repository".

   2. Configure access to the repository using the ArgoCD UI. Under Settings configure the following:

      • Repositories - Add the connection information. The URL must end in

        .git

        , for example,

        https://repo.example.com/repo.git

        and credentials.
      • Certificates - Add the public certificate for the repository, if needed.

   3. Modify the two ArgoCD applications,

      out/argocd/deployment/clusters-app.yaml

      and

      out/argocd/deployment/policies-app.yaml

      , based on your Git repository:
      • Update the URL to point to the Git repository. The URL ends with

        .git

        , for example,

        https://repo.example.com/repo.git

        .
      • The

        targetRevision

        indicates which Git repository branch to monitor.

      • path

        specifies the path to the

        SiteConfig

        and

        PolicyGenerator

        or

        PolicyGentemplate

        CRs, respectively.

2. To install the GitOps ZTP plugin, patch the ArgoCD instance in the hub cluster with the relevant multicluster engine (MCE) subscription image. Customize the patch file that you previously extracted into the

   out/argocd/deployment/

   directory for your environment.

   1. Select the

      multicluster-operators-subscription

      image that matches your RHACM version.
      • For RHACM 2.8 and 2.9, use the

        registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v<rhacm_version>

        image.
      • For RHACM 2.10 and later, use the

        registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v<rhacm_version>

        image.
      Important

      The version of the

      multicluster-operators-subscription

      image must match the RHACM version. Beginning with the MCE 2.10 release, RHEL 9 is the base image for

      multicluster-operators-subscription

      images.

      Click

      [Expand for Operator list]

      in the "Platform Aligned Operators" table in OpenShift Operator Life Cycles to view the complete supported Operators matrix for OpenShift Container Platform.

   2. Modify the

      out/argocd/deployment/argocd-openshift-gitops-patch.json

      file with the

      multicluster-operators-subscription

      image that matches your RHACM version:

      {
        "args": [
          "-c",
          "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 

      1

      
        ],
        "command": [
          "/bin/bash"
        ],
        "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 

      2

      3

      
        "name": "policy-generator-install",
        "imagePullPolicy": "Always",
        "volumeMounts": [
          {
            "mountPath": "/.config",
            "name": "kustomize"
          }
        ]
      }

      1

      Optional: For RHEL 9 images, copy the required universal executable in the /policy-generator/PolicyGenerator-not-fips-compliant folder for the ArgoCD version.

      2

      Match the multicluster-operators-subscription image to the RHACM version.

      3

      In disconnected environments, replace the URL for the multicluster-operators-subscription image with the disconnected registry equivalent for your environment.

   3. Patch the ArgoCD instance. Run the following command:

      $ oc patch argocd openshift-gitops \
      -n openshift-gitops --type=merge \
      --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json

3. In RHACM 2.7 and later, the multicluster engine enables the

   cluster-proxy-addon

   feature by default. Apply the following patch to disable the

   cluster-proxy-addon

   feature and remove the relevant hub cluster and managed pods that are responsible for this add-on. Run the following command:

   $ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json

4. Apply the pipeline configuration to your hub cluster by running the following command:

   $ oc apply -k out/argocd/deployment

5. Optional: If you have existing ArgoCD applications, verify that the

   PrunePropagationPolicy=background

   policy is set in the

   Application

   resource by running the following command:

   $ oc -n openshift-gitops get applications.argoproj.io  \
   clusters -o jsonpath='{.spec.syncPolicy.syncOptions}' |jq

   Example output for an existing policy

   [
     "CreateNamespace=true",
     "PrunePropagationPolicy=background",
     "RespectIgnoreDifferences=true"
   ]

   1. If the

      spec.syncPolicy.syncOption

      field does not contain a

      PrunePropagationPolicy

      parameter or

      PrunePropagationPolicy

      is set to the

      foreground

      value, set the policy to

      background

      in the

      Application

      resource. See the following example:

      kind: Application
      spec:
        syncPolicy:
          syncOptions:
          - PrunePropagationPolicy=background

   Setting the

   background

   deletion policy ensures that the

   ManagedCluster

   CR and all its associated resources are deleted.

Procedure

1. Create a directory structure with separate paths for the

   SiteConfig

   and

   PolicyGenerator

   or

   PolicyGentemplate

   CRs.
   Note

   Keep

   SiteConfig

   and

   PolicyGenerator

   or

   PolicyGentemplate

   CRs in separate directories. Both the

   SiteConfig

   and

   PolicyGenerator

   or

   PolicyGentemplate

   directories must contain a

   kustomization.yaml

   file that explicitly includes the files in that directory.

2. Export the

   argocd

   directory from the

   ztp-site-generate

   container image using the following commands:

   $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.20

   $ mkdir -p ./out

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.20 extract /home/ztp --tar | tar x -C ./out

3. Check that the

   out

   directory contains the following subdirectories:

   • out/extra-manifest

     contains the source CR files that

     SiteConfig

     uses to generate extra manifest

     configMap

     .

   • out/source-crs

     contains the source CR files that

     PolicyGenerator

     uses to generate the Red Hat Advanced Cluster Management (RHACM) policies.

   • out/argocd/deployment

     contains patches and YAML files to apply on the hub cluster for use in the next step of this procedure.

   • out/argocd/example

     contains the examples for

     SiteConfig

     and

     PolicyGenerator

     or

     PolicyGentemplate

     files that represent the recommended configuration.
4. Copy the

   out/source-crs

   folder and contents to the

   PolicyGenerator

   or

   PolicyGentemplate

   directory.

5. The out/extra-manifests directory contains the reference manifests for a RAN DU cluster. Copy the

   out/extra-manifests

   directory into the

   SiteConfig

   folder. This directory should contain CRs from the

   ztp-site-generate

   container only. Do not add user-provided CRs here. If you want to work with user-provided CRs you must create another directory for that content. For example:

   example/
     ├── acmpolicygenerator
     │   ├── kustomization.yaml
     │   └── source-crs/
     ├── policygentemplates 

   1

   
     │   ├── kustomization.yaml
     │   └── source-crs/
     └── siteconfig
           ├── extra-manifests
           └── kustomization.yaml

   1

   Using PolicyGenTemplate CRs to manage and deploy policies to manage clusters will be deprecated in a future OpenShift Container Platform release. Equivalent and improved functionality is available by using Red Hat Advanced Cluster Management (RHACM) and PolicyGenerator CRs.

6. Commit the directory structure and the

   kustomization.yaml

   files and push to your Git repository. The initial push to Git should include the

   kustomization.yaml

   files.

Procedure

1. Create a directory structure with separate paths for the

   SiteConfig

   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

   /siteconfig

   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 

   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 

   7

   
   │       ├── common-ranGen.yaml
   │       ├── group-du-sno-ranGen.yaml
   │       ├── group-du-sno-validator-ranGen.yaml
   │       ├── helix56-v414.yaml
   │       ├── kustomization.yaml 

   8

   
   │       ├── ns.yaml
   │       └── source-crs/ 

   9

   
   │         └── reference-crs/ 

   10

   
   │         └── custom-crs/ 

   11

   
   └── siteconfig
       ├── kustomization.yaml
       ├── version_4.13
       │   ├── helix56-v413.yaml
       │   ├── kustomization.yaml
       │   ├── extra-manifest/ 

   12

   
       │   └── custom-manifest/ 

   13

   
       └── version_4.14
           ├── helix57-v414.yaml
           ├── kustomization.yaml
           ├── extra-manifest/ 

   14

   
           └── custom-manifest/ 

   15

   1

   Create a top-level kustomization YAML file.

   2 7

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

   3 8

   Create a kustomization.yaml file for each version.

   4 9

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

   5 10

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

   6 11

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

   12 14

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

   13 15

   Create a folder to hold user-provided manifests.

   Note

   In the previous example, each version subdirectory in the custom

   /siteconfig

   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. If you use user-provided CRs, the last directory listed under

   extraManifests.searchPaths

   in the

   SiteConfig

   CR must be the directory containing user-provided CRs.

4. Edit the

   SiteConfig

   CR to include the search paths of any directories you have created. The first directory that is listed under

   extraManifests.searchPaths

   must be the directory containing the reference manifests. Consider the order in which the directories are listed. In cases where directories contain files with the same name, the file in the final directory takes precedence.

   Example SiteConfig CR

   extraManifests:
       searchPaths:
       - extra-manifest/ 

   1

   
       - custom-manifest/ 

   2

   1

   The directory containing the reference manifests must be listed first under extraManifests.searchPaths.

   2

   If you are using user-provided CRs, the last directory listed under extraManifests.searchPaths in the SiteConfig CR must be the directory containing those user-provided CRs.

5. 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 

   1

   
   #- version_4.14 

   2

   1

   Activate version 4.13.

   2

   Use comments to deactivate a version.

Procedure

1. Create a policy to add the

   cluster.open-cluster-management.io/backup=cluster-activation

   label to all

   BareMetalHost

   resources that have the

   infraenvs.agent-install.openshift.io

   label. Save the policy as

   BareMetalHostBackupPolicy.yaml

   .

   The following example adds the

   cluster.open-cluster-management.io/backup

   label to all

   BareMetalHost

   resources that have the

   infraenvs.agent-install.openshift.io

   label:

   Example Policy

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: bmh-cluster-activation-label
     annotations:
       policy.open-cluster-management.io/description: Policy used to add the cluster.open-cluster-management.io/backup=cluster-activation label to all BareMetalHost resources
   spec:
     disabled: false
     policy-templates:
       - objectDefinition:
           apiVersion: policy.open-cluster-management.io/v1
           kind: ConfigurationPolicy
           metadata:
             name: set-bmh-backup-label
           spec:
             object-templates-raw: |
               {{- /* Set cluster-activation label on all BMH resources */ -}}
               {{- $infra_label := "infraenvs.agent-install.openshift.io" }}
               {{- range $bmh := (lookup "metal3.io/v1alpha1" "BareMetalHost" "" "" $infra_label).items }}
                   - complianceType: musthave
                     objectDefinition:
                       kind: BareMetalHost
                       apiVersion: metal3.io/v1alpha1
                       metadata:
                         name: {{ $bmh.metadata.name }}
                         namespace: {{ $bmh.metadata.namespace }}
                         labels:
                           cluster.open-cluster-management.io/backup: cluster-activation 

   1

   
               {{- end }}
             remediationAction: enforce
             severity: high
   ---
   apiVersion: cluster.open-cluster-management.io/v1beta1
   kind: Placement
   metadata:
     name: bmh-cluster-activation-label-pr
   spec:
     predicates:
       - requiredClusterSelector:
           labelSelector:
             matchExpressions:
               - key: name
                 operator: In
                 values:
                   - local-cluster
   ---
   apiVersion: policy.open-cluster-management.io/v1
   kind: PlacementBinding
   metadata:
     name: bmh-cluster-activation-label-binding
   placementRef:
     name: bmh-cluster-activation-label-pr
     apiGroup: cluster.open-cluster-management.io
     kind: Placement
   subjects:
     - name: bmh-cluster-activation-label
       apiGroup: policy.open-cluster-management.io
       kind: Policy
   ---
   apiVersion: cluster.open-cluster-management.io/v1beta2
   kind: ManagedClusterSetBinding
   metadata:
     name: default
     namespace: default
   spec:
     clusterSet: default

   1

   If you apply the cluster.open-cluster-management.io/backup: cluster-activation label to BareMetalHost resources, the RHACM cluster backs up those resources. You can restore the BareMetalHost resources if the active cluster becomes unavailable, when restoring the hub activation resources.

2. Apply the policy by running the following command:

   $ oc apply -f BareMetalHostBackupPolicy.yaml

Verification

1. Find all

   BareMetalHost

   resources with the label

   infraenvs.agent-install.openshift.io

   by running the following command:

   $ oc get BareMetalHost -A -l infraenvs.agent-install.openshift.io

   Example output

   NAMESPACE      NAME             STATE   CONSUMER   ONLINE   ERROR   AGE
   baremetal-ns   baremetal-name                      false            50s

2. Verify that the policy has applied the label

   cluster.open-cluster-management.io/backup=cluster-activation

   to all these resources, by running the following command:

   $ oc get BareMetalHost -A -l infraenvs.agent-install.openshift.io,cluster.open-cluster-management.io/backup=cluster-activation

   Example output

   NAMESPACE      NAME             STATE   CONSUMER   ONLINE   ERROR   AGE
   baremetal-ns   baremetal-name                      false            50s

   The output must show the same list as in the previous step, which listed all

   BareMetalHost

   resources with the label

   infraenvs.agent-install.openshift.io

   . This confirms that all the

   BareMetalHost

   resources with the

   infraenvs.agent-install.openshift.io

   label also have the

   cluster.open-cluster-management.io/backup: cluster-activation

   label.

   The following example shows a

   BareMetalHost

   resource with the

   infraenvs.agent-install.openshift.io

   label. The resource must also have the

   cluster.open-cluster-management.io/backup: cluster-activation

   label, which was added by the policy created in step 1.

   apiVersion: metal3.io/v1alpha1
   kind: BareMetalHost
   metadata:
     labels:
       cluster.open-cluster-management.io/backup: cluster-activation
       infraenvs.agent-install.openshift.io: value
     name: baremetal-name
     namespace: baremetal-ns

1. Label all existing clusters with the

   ztp-done

   label.
2. Stop the ArgoCD applications.
3. Install the new GitOps ZTP tools.
4. Update required content and optional changes in the Git repository.
5. Enable pulling the ISO images for the desired OpenShift Container Platform version.
6. Update and restart the application configuration.

Procedure

1. Get the latest version of the GitOps ZTP container that has the custom resources (CRs) used to configure Red Hat OpenShift GitOps for use with GitOps ZTP.

2. Extract the

   argocd/deployment

   directory by using the following commands:

   $ mkdir -p ./update

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.20 extract /home/ztp --tar | tar x -C ./update

   The

   /update

   directory contains the following subdirectories:

   • update/extra-manifest

     : contains the source CR files that the

     SiteConfig

     CR uses to generate the extra manifest

     configMap

     .

   • update/source-crs

     : contains the source CR files that the

     PolicyGenerator

     or

     PolicyGentemplate

     CR uses to generate the Red Hat Advanced Cluster Management (RHACM) policies.

   • update/argocd/deployment

     : contains patches and YAML files to apply on the hub cluster for use in the next step of this procedure.

   • update/argocd/example

     : contains example

     SiteConfig

     and

     PolicyGenerator

     or

     PolicyGentemplate

     files that represent the recommended configuration.

3. Update the

   clusters-app.yaml

   and

   policies-app.yaml

   files to reflect the name of your applications and the URL, branch, and path for your Git repository.

   If the upgrade includes changes that results in obsolete policies, the obsolete policies should be removed prior to performing the upgrade.

4. Diff the changes between the configuration and deployment source CRs in the

   /update

   folder and Git repo where you manage your fleet site CRs. Apply and push the required changes to your site repository.
   Important

   When you update GitOps ZTP to the latest version, you must apply the changes from the

   update/argocd/deployment

   directory to your site repository. Do not use older versions of the

   argocd/deployment/

   files.

Procedure

1. Find a label selector that lists the managed clusters that were deployed with GitOps Zero Touch Provisioning (ZTP), such as

   local-cluster!=true

   :

   $ oc get managedcluster -l 'local-cluster!=true'

2. Ensure that the resulting list contains all the managed clusters that were deployed with GitOps ZTP, and then use that selector to add the

   ztp-done

   label:

   $ oc label managedcluster -l 'local-cluster!=true' ztp-done=

Procedure

1. Perform a non-cascaded delete on the

   clusters

   application to leave all generated resources in place:

   $ oc delete -f update/argocd/deployment/clusters-app.yaml

2. Perform a cascaded delete on the

   policies

   application to remove all previous policies:

   $ oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge

   $ oc delete -f update/argocd/deployment/policies-app.yaml

Procedure

1. To install the GitOps ZTP plugin, patch the ArgoCD instance in the hub cluster with the relevant multicluster engine (MCE) subscription image. Customize the patch file that you previously extracted into the

   out/argocd/deployment/

   directory for your environment.

   1. Select the

      multicluster-operators-subscription

      image that matches your RHACM version.
      • For RHACM 2.8 and 2.9, use the

        registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v<rhacm_version>

        image.
      • For RHACM 2.10 and later, use the

        registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v<rhacm_version>

        image.
      Important

      The version of the

      multicluster-operators-subscription

      image must match the RHACM version. Beginning with the MCE 2.10 release, RHEL 9 is the base image for

      multicluster-operators-subscription

      images.

      Click

      [Expand for Operator list]

      in the "Platform Aligned Operators" table in OpenShift Operator Life Cycles to view the complete supported Operators matrix for OpenShift Container Platform.

   2. Modify the

      out/argocd/deployment/argocd-openshift-gitops-patch.json

      file with the

      multicluster-operators-subscription

      image that matches your RHACM version:

      {
        "args": [
          "-c",
          "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 

      1

      
        ],
        "command": [
          "/bin/bash"
        ],
        "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 

      2

      3

      
        "name": "policy-generator-install",
        "imagePullPolicy": "Always",
        "volumeMounts": [
          {
            "mountPath": "/.config",
            "name": "kustomize"
          }
        ]
      }

      1

      Optional: For RHEL 9 images, copy the required universal executable in the /policy-generator/PolicyGenerator-not-fips-compliant folder for the ArgoCD version.

      2

      Match the multicluster-operators-subscription image to the RHACM version.

      3

      In disconnected environments, replace the URL for the multicluster-operators-subscription image with the disconnected registry equivalent for your environment.

   3. Patch the ArgoCD instance. Run the following command:

      $ oc patch argocd openshift-gitops \
      -n openshift-gitops --type=merge \
      --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json

2. In RHACM 2.7 and later, the multicluster engine enables the

   cluster-proxy-addon

   feature by default. Apply the following patch to disable the

   cluster-proxy-addon

   feature and remove the relevant hub cluster and managed pods that are responsible for this add-on. Run the following command:

   $ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json

3. Apply the pipeline configuration to your hub cluster by running the following command:

   $ oc apply -k out/argocd/deployment

Procedure

1. Open the

   AgentServiceConfig

   CR to update the

   spec.osImages

   field by running the following command:

   $ oc edit AgentServiceConfig

2. Update the

   spec.osImages

   field in the

   AgentServiceConfig

   CR:

   apiVersion: agent-install.openshift.io/v1beta1
   kind: AgentServiceConfig
   metadata:
    name: agent
   spec:
   # ...
     osImages:
       - cpuArchitecture: x86_64
         openshiftVersion: "4.20"
         rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
         url: https://<host>/<path>/rhcos-live.x86_64.iso

   where:

   <host>

   Specifies the fully qualified domain name (FQDN) for the target mirror registry HTTP server.

   <path>

   Specifies the path to the image on the target mirror registry.

3. Save and quit the editor to apply the changes.

Procedure

1. Create a YAML secret file containing credentials for the host Baseboard Management Controller (BMC) and a pull secret required for installing OpenShift and all add-on cluster Operators:

   1. Save the following YAML as the file

      example-sno-secret.yaml

      :

      apiVersion: v1
      kind: Secret
      metadata:
        name: example-sno-bmc-secret
        namespace: example-sno 

      1

      
      data: 

      2

      
        password: <base64_password>
        username: <base64_username>
      type: Opaque
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: pull-secret
        namespace: example-sno  

      3

      
      data:
        .dockerconfigjson: <pull_secret> 

      4

      
      type: kubernetes.io/dockerconfigjson

      1

      Must match the namespace configured in the related SiteConfig CR

      2

      Base64-encoded values for password and username

      3

      Must match the namespace configured in the related SiteConfig CR

      4

      Base64-encoded pull secret

2. Add the relative path to

   example-sno-secret.yaml

   to the

   kustomization.yaml

   file that you use to install the cluster.

Procedure

1. Create the

   InfraEnv

   CR and edit the

   spec.kernelArguments

   specification to configure kernel arguments.

   1. Save the following YAML in an

      InfraEnv-example.yaml

      file:
      Note

      The

      InfraEnv

      CR in this example uses template syntax such as

      {{ .Cluster.ClusterName }}

      that is populated based on values in the

      SiteConfig

      CR. The

      SiteConfig

      CR automatically populates values for these templates during deployment. Do not edit the templates manually.

      apiVersion: agent-install.openshift.io/v1beta1
      kind: InfraEnv
      metadata:
        annotations:
          argocd.argoproj.io/sync-wave: "1"
        name: "{{ .Cluster.ClusterName }}"
        namespace: "{{ .Cluster.ClusterName }}"
      spec:
        clusterRef:
          name: "{{ .Cluster.ClusterName }}"
          namespace: "{{ .Cluster.ClusterName }}"
        kernelArguments:
          - operation: append 

      1

      
            value: audit=0 

      2

      
          - operation: append
            value: trace=1
        sshAuthorizedKey: "{{ .Site.SshPublicKey }}"
        proxy: "{{ .Cluster.ProxySettings }}"
        pullSecretRef:
          name: "{{ .Site.PullSecretRef.Name }}"
        ignitionConfigOverride: "{{ .Cluster.IgnitionConfigOverride }}"
        nmStateConfigLabelSelector:
          matchLabels:
            nmstate-label: "{{ .Cluster.ClusterName }}"
        additionalNTPSources: "{{ .Cluster.AdditionalNTPSources }}"

      1

      Specify the append operation to add a kernel argument.

      2

      Specify the kernel argument you want to configure. This example configures the audit kernel argument and the trace kernel argument.

2. Commit the

   InfraEnv-example.yaml

   CR to the same location in your Git repository that has the

   SiteConfig

   CR and push your changes. The following example shows a sample Git repository structure:

   ~/example-ztp/install
             └── site-install
                  ├── siteconfig-example.yaml
                  ├── InfraEnv-example.yaml
                  ...

3. Edit the

   spec.clusters.crTemplates

   specification in the

   SiteConfig

   CR to reference the

   InfraEnv-example.yaml

   CR in your Git repository:

   clusters:
     crTemplates:
       InfraEnv: "InfraEnv-example.yaml"

   When you are ready to deploy your cluster by committing and pushing the

   SiteConfig

   CR, the build pipeline uses the custom

   InfraEnv-example

   CR in your Git repository to configure the infrastructure environment, including the custom kernel arguments.

1. Begin an SSH session with the target host:

   $ ssh -i /path/to/privatekey core@<host_name>

2. View the system’s kernel arguments by using the following command:

   $ cat /proc/cmdline

Procedure

1. Create the required managed cluster secrets on the hub cluster. These resources must be in a namespace with a name matching the cluster name. For example, in

   out/argocd/example/siteconfig/example-sno.yaml

   , the cluster name and namespace is

   example-sno

   .

   1. Export the cluster namespace by running the following command:

      $ export CLUSTERNS=example-sno

   2. Create the namespace:

      $ oc create namespace $CLUSTERNS

2. Create pull secret and BMC

   Secret

   CRs for the managed cluster. The pull secret must contain all the credentials necessary for installing OpenShift Container Platform and all required Operators. See "Creating the managed bare-metal host secrets" for more information.
   Note

   The secrets are referenced from the

   SiteConfig

   custom resource (CR) by name. The namespace must match the

   SiteConfig

   namespace.

3. Create a

   SiteConfig

   CR for your cluster in your local clone of the Git repository:

   1. Choose the appropriate example for your CR from the

      out/argocd/example/siteconfig/

      folder. The folder includes example files for single node, three-node, and standard clusters:

      • example-sno.yaml

      • example-3node.yaml

      • example-standard.yaml

   2. Change the cluster and host details in the example file to match the type of cluster you want. For example:

      Example single-node OpenShift SiteConfig CR

      # example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
      ---
      apiVersion: ran.openshift.io/v1
      kind: SiteConfig
      metadata:
        name: "example-sno"
        namespace: "example-sno"
      spec:
        baseDomain: "example.com"
        pullSecretRef:
          name: "assisted-deployment-pull-secret"
        clusterImageSetNameRef: "openshift-4.18"
        sshPublicKey: "ssh-rsa AAAA..."
        clusters:
          - clusterName: "example-sno"
            networkType: "OVNKubernetes"
            # installConfigOverrides is a generic way of passing install-config
            # parameters through the siteConfig.  The 'capabilities' field configures
            # the composable openshift feature.  In this 'capabilities' setting, we
            # remove all the optional set of components.
            # Notes:
            # - OperatorLifecycleManager is needed for 4.15 and later
            # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
            # - Ingress is needed for 4.16 and later
            installConfigOverrides: |
              {
                "capabilities": {
                  "baselineCapabilitySet": "None",
                  "additionalEnabledCapabilities": [
                    "NodeTuning",
                    "OperatorLifecycleManager",
                    "Ingress"
                  ]
                }
              }
            # It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+.
            # The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest.
            # extraManifestPath: sno-extra-manifest
            clusterLabels:
              # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples
              du-profile: "latest"
              # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates:
              # ../acmpolicygenerator/common-ranGen.yaml will apply to all clusters with 'common: true'
              common: true
              # ../policygentemplates/group-du-sno-ranGen.yaml will apply to all clusters with 'group-du-sno: ""'
              group-du-sno: ""
              # ../policygentemplates/example-sno-site.yaml will apply to all clusters with 'sites: "example-sno"'
              # Normally this should match or contain the cluster name so it only applies to a single cluster
              sites: "example-sno"
            clusterNetwork:
              - cidr: 1001:1::/48
                hostPrefix: 64
            machineNetwork:
              - cidr: 1111:2222:3333:4444::/64
            serviceNetwork:
              - 1001:2::/112
            additionalNTPSources:
              - 1111:2222:3333:4444::2
            # Initiates the cluster for workload partitioning. Setting specific reserved/isolated CPUSets is done via PolicyTemplate
            # please see Workload Partitioning Feature for a complete guide.
            cpuPartitioningMode: AllNodes
            # Optionally; This can be used to override the KlusterletAddonConfig that is created for this cluster:
            #crTemplates:
            #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml"
            nodes:
              - hostName: "example-node1.example.com"
                role: "master"
                # Optionally; This can be used to configure desired BIOS setting on a host:
                #biosConfigRef:
                #  filePath: "example-hw.profile"
                bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
                bmcCredentialsName:
                  name: "example-node1-bmh-secret"
                bootMACAddress: "AA:BB:CC:DD:EE:11"
                # Use UEFISecureBoot to enable secure boot.
                bootMode: "UEFISecureBoot"
                rootDeviceHints:
                  deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0"
                #crTemplates:
                #  BareMetalHost: "bmhOverride.yaml"
                # disk partition at `/var/lib/containers` with ignitionConfigOverride. Some values must be updated. See DiskPartitionContainer.md for more details
                ignitionConfigOverride: |
                  {
                    "ignition": {
                      "version": "3.2.0"
                    },
                    "storage": {
                      "disks": [
                        {
                          "device": "/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62",
                          "partitions": [
                            {
                              "label": "var-lib-containers",
                              "sizeMiB": 0,
                              "startMiB": 250000
                            }
                          ],
                          "wipeTable": false
                        }
                      ],
                      "filesystems": [
                        {
                          "device": "/dev/disk/by-partlabel/var-lib-containers",
                          "format": "xfs",
                          "mountOptions": [
                            "defaults",
                            "prjquota"
                          ],
                          "path": "/var/lib/containers",
                          "wipeFilesystem": true
                        }
                      ]
                    },
                    "systemd": {
                      "units": [
                        {
                          "contents": "# Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target",
                          "enabled": true,
                          "name": "var-lib-containers.mount"
                        }
                      ]
                    }
                  }
                nodeNetwork:
                  interfaces:
                    - name: eno1
                      macAddress: "AA:BB:CC:DD:EE:11"
                  config:
                    interfaces:
                      - name: eno1
                        type: ethernet
                        state: up
                        ipv4:
                          enabled: false
                        ipv6:
                          enabled: true
                          address:
                            # For SNO sites with static IP addresses, the node-specific,
                            # API and Ingress IPs should all be the same and configured on
                            # the interface
                            - ip: 1111:2222:3333:4444::aaaa:1
                              prefix-length: 64
                    dns-resolver:
                      config:
                        search:
                          - example.com
                        server:
                          - 1111:2222:3333:4444::2
                    routes:
                      config:
                        - destination: ::/0
                          next-hop-interface: eno1
                          next-hop-address: 1111:2222:3333:4444::1
                          table-id: 254

      Note

      For more information about BMC addressing, see the "Additional resources" section. The

      installConfigOverrides

      and

      ignitionConfigOverride

      fields are expanded in the example for ease of readability.

      Note

      To override the default

      BareMetalHost

      CR for a node, you can reference the override CR in the node-level

      crTemplates

      field in the

      SiteConfig

      CR. Ensure that you set the

      argocd.argoproj.io/sync-wave: "3"

      annotation in your override

      BareMetalHost

      CR.

   3. You can inspect the default set of extra-manifest

      MachineConfig

      CRs in

      out/argocd/extra-manifest

      . It is automatically applied to the cluster when it is installed.

   4. Optional: To provision additional install-time manifests on the provisioned cluster, create a directory in your Git repository, for example,

      sno-extra-manifest/

      , and add your custom manifest CRs to this directory. If your

      SiteConfig.yaml

      refers to this directory in the

      extraManifestPath

      field, any CRs in this referenced directory are appended to the default set of extra manifests.
      Enabling the crun OCI container runtime

      For optimal cluster performance, enable crun for master and worker nodes in single-node OpenShift, single-node OpenShift with additional worker nodes, three-node OpenShift, and standard clusters.

      Enable crun in a

      ContainerRuntimeConfig

      CR as an additional Day 0 install-time manifest to avoid the cluster having to reboot.

      The

      enable-crun-master.yaml

      and

      enable-crun-worker.yaml

      CR files are in the

      out/source-crs/optional-extra-manifest/

      folder that you can extract from the

      ztp-site-generate

      container. For more information, see "Customizing extra installation manifests in the GitOps ZTP pipeline".

4. Add the

   SiteConfig

   CR to the

   kustomization.yaml

   file in the

   generators

   section, similar to the example shown in

   out/argocd/example/siteconfig/kustomization.yaml

   .

5. Commit the

   SiteConfig

   CR and associated

   kustomization.yaml

   changes in your Git repository and push the changes.

   The ArgoCD pipeline detects the changes and begins the managed cluster deployment.

1. The Assisted Service Operator installs OpenShift Container Platform on the cluster. You can monitor the progress of cluster installation from the RHACM dashboard or from the command line by running the following commands:

   1. Export the cluster name:

      $ export CLUSTER=<clusterName>

   2. Query the

      AgentClusterInstall

      CR for the managed cluster:

      $ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq

   3. Get the installation events for the cluster:

      $ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}')  | jq '.[-2,-1]'

Procedure

1. Check that the installation CRs were created by using the following command:

   $ oc get AgentClusterInstall -n <cluster_name>

   If no object is returned, use the following steps to troubleshoot the ArgoCD pipeline flow from

   SiteConfig

   files to the installation CRs.

2. Verify that the

   ManagedCluster

   CR was generated using the

   SiteConfig

   CR on the hub cluster:

   $ oc get managedcluster

3. If the

   ManagedCluster

   is missing, check if the

   clusters

   application failed to synchronize the files from the Git repository to the hub cluster:

   $ oc get applications.argoproj.io -n openshift-gitops clusters -o yaml

   1. To identify error logs for the managed cluster, inspect the

      status.operationState.syncResult.resources

      field. For example, if an invalid value is assigned to the

      extraManifestPath

      in the

      SiteConfig

      CR, an error similar to the following is generated:

      syncResult:
        resources:
        - group: ran.openshift.io
          kind: SiteConfig
          message: The Kubernetes API could not find ran.openshift.io/SiteConfig for
            requested resource spoke-sno/spoke-sno. Make sure the "SiteConfig" CRD is
            installed on the destination cluster

   2. To see a more detailed

      SiteConfig

      error, complete the following steps:
      1. In the Argo CD dashboard, click the SiteConfig resource that Argo CD is trying to sync.

      2. Check the DESIRED MANIFEST tab to find the

         siteConfigError

         field.

         siteConfigError: >- Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-1081291903: stat sno-extra-manifest: no such file or directory

   3. Check the

      Status.Sync

      field. If there are log errors, the

      Status.Sync

      field could indicate an

      Unknown

      error:

      Status:
        Sync:
          Compared To:
            Destination:
              Namespace:  clusters-sub
              Server:     https://kubernetes.default.svc
            Source:
              Path:             sites-config
              Repo URL:         https://git.com/ran-sites/siteconfigs/.git
              Target Revision:  master
          Status:               Unknown

Procedure

1. Disable TLS in the

   Provisioning

   resource by running the following command:

   $ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'

2. Continue the steps to deploy your single-node OpenShift cluster.

Procedure

1. Remove a site and the associated CRs by removing the associated

   SiteConfig

   and

   PolicyGenerator

   or

   PolicyGentemplate

   files from the

   kustomization.yaml

   file.

2. Add the following

   syncOptions

   field to your

   SiteConfig

   application.

   kind: Application
   spec:
     syncPolicy:
       syncOptions:
       - PrunePropagationPolicy=background

   When you run the GitOps ZTP pipeline again, the generated CRs are removed.

3. Optional: If you want to permanently remove a site, you should also remove the

   SiteConfig

   and site-specific

   PolicyGenerator

   or

   PolicyGentemplate

   files from the Git repository.
4. Optional: If you want to remove a site temporarily, for example when redeploying a site, you can leave the

   SiteConfig

   and site-specific

   PolicyGenerator

   or

   PolicyGentemplate

   CRs in the Git repository.

Procedure

1. Remove the affected

   PolicyGenerator

   or

   PolicyGentemplate

   files from the Git repository, commit and push to the remote repository.
2. Wait for the changes to synchronize through the application and the affected policies to be removed from the hub cluster.

3. Add the updated

   PolicyGenerator

   or

   PolicyGentemplate

   files back to the Git repository, and then commit and push to the remote repository.
   Note

   Removing GitOps Zero Touch Provisioning (ZTP) policies from the Git repository, and as a result also removing them from the hub cluster, does not affect the configuration of the managed cluster. The policy and CRs managed by that policy remains in place on the managed cluster.

4. Optional: As an alternative, after making changes to

   PolicyGenerator

   or

   PolicyGentemplate

   CRs that result in obsolete policies, you can remove these policies from the hub cluster manually. You can delete policies from the RHACM console using the Governance tab or by running the following command:

   $ oc delete policy -n <namespace> <policy_name>

Procedure

1. Detach all clusters from Red Hat Advanced Cluster Management (RHACM) on the hub cluster.

2. Delete the

   kustomization.yaml

   file in the

   deployment

   directory using the following command:

   $ oc delete -k out/argocd/deployment

3. Commit and push your changes to the site repository.

Procedure

1. Create an output folder by running the following command:

   $ mkdir -p ./out

2. Export the

   argocd

   directory from the

   ztp-site-generate

   container image:

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.20 extract /home/ztp --tar | tar x -C ./out

   The

   ./out

   directory has the reference

   PolicyGenerator

   and

   SiteConfig

   CRs in the

   out/argocd/example/

   folder.

   Example output

   out
    └── argocd
         └── example
              ├── acmpolicygenerator
              │     ├── {policy-prefix}common-ranGen.yaml
              │     ├── {policy-prefix}example-sno-site.yaml
              │     ├── {policy-prefix}group-du-sno-ranGen.yaml
              │     ├── {policy-prefix}group-du-sno-validator-ranGen.yaml
              │     ├── ...
              │     ├── kustomization.yaml
              │     └── ns.yaml
              └── siteconfig
                     ├── example-sno.yaml
                     ├── KlusterletAddonConfigOverride.yaml
                     └── kustomization.yaml

3. Create an output folder for the site installation CRs:

   $ mkdir -p ./site-install

4. Modify the example

   SiteConfig

   CR for the cluster type that you want to install. Copy

   example-sno.yaml

   to

   site-1-sno.yaml

   and modify the CR to match the details of the site and bare-metal host that you want to install, for example:

   # example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
   ---
   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "example-sno"
     namespace: "example-sno"
   spec:
     baseDomain: "example.com"
     pullSecretRef:
       name: "assisted-deployment-pull-secret"
     clusterImageSetNameRef: "openshift-4.18"
     sshPublicKey: "ssh-rsa AAAA..."
     clusters:
       - clusterName: "example-sno"
         networkType: "OVNKubernetes"
         # installConfigOverrides is a generic way of passing install-config
         # parameters through the siteConfig.  The 'capabilities' field configures
         # the composable openshift feature.  In this 'capabilities' setting, we
         # remove all the optional set of components.
         # Notes:
         # - OperatorLifecycleManager is needed for 4.15 and later
         # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
         # - Ingress is needed for 4.16 and later
         installConfigOverrides: |
           {
             "capabilities": {
               "baselineCapabilitySet": "None",
               "additionalEnabledCapabilities": [
                 "NodeTuning",
                 "OperatorLifecycleManager",
                 "Ingress"
               ]
             }
           }
         # It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+.
         # The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest.
         # extraManifestPath: sno-extra-manifest
         clusterLabels:
           # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples
           du-profile: "latest"
           # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates:
           # ../acmpolicygenerator/common-ranGen.yaml will apply to all clusters with 'common: true'
           common: true
           # ../policygentemplates/group-du-sno-ranGen.yaml will apply to all clusters with 'group-du-sno: ""'
           group-du-sno: ""
           # ../policygentemplates/example-sno-site.yaml will apply to all clusters with 'sites: "example-sno"'
           # Normally this should match or contain the cluster name so it only applies to a single cluster
           sites: "example-sno"
         clusterNetwork:
           - cidr: 1001:1::/48
             hostPrefix: 64
         machineNetwork:
           - cidr: 1111:2222:3333:4444::/64
         serviceNetwork:
           - 1001:2::/112
         additionalNTPSources:
           - 1111:2222:3333:4444::2
         # Initiates the cluster for workload partitioning. Setting specific reserved/isolated CPUSets is done via PolicyTemplate
         # please see Workload Partitioning Feature for a complete guide.
         cpuPartitioningMode: AllNodes
         # Optionally; This can be used to override the KlusterletAddonConfig that is created for this cluster:
         #crTemplates:
         #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml"
         nodes:
           - hostName: "example-node1.example.com"
             role: "master"
             # Optionally; This can be used to configure desired BIOS setting on a host:
             #biosConfigRef:
             #  filePath: "example-hw.profile"
             bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
             bmcCredentialsName:
               name: "example-node1-bmh-secret"
             bootMACAddress: "AA:BB:CC:DD:EE:11"
             # Use UEFISecureBoot to enable secure boot.
             bootMode: "UEFISecureBoot"
             rootDeviceHints:
               deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0"
             #crTemplates:
             #  BareMetalHost: "bmhOverride.yaml"
             # disk partition at `/var/lib/containers` with ignitionConfigOverride. Some values must be updated. See DiskPartitionContainer.md for more details
             ignitionConfigOverride: |
               {
                 "ignition": {
                   "version": "3.2.0"
                 },
                 "storage": {
                   "disks": [
                     {
                       "device": "/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62",
                       "partitions": [
                         {
                           "label": "var-lib-containers",
                           "sizeMiB": 0,
                           "startMiB": 250000
                         }
                       ],
                       "wipeTable": false
                     }
                   ],
                   "filesystems": [
                     {
                       "device": "/dev/disk/by-partlabel/var-lib-containers",
                       "format": "xfs",
                       "mountOptions": [
                         "defaults",
                         "prjquota"
                       ],
                       "path": "/var/lib/containers",
                       "wipeFilesystem": true
                     }
                   ]
                 },
                 "systemd": {
                   "units": [
                     {
                       "contents": "# Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target",
                       "enabled": true,
                       "name": "var-lib-containers.mount"
                     }
                   ]
                 }
               }
             nodeNetwork:
               interfaces:
                 - name: eno1
                   macAddress: "AA:BB:CC:DD:EE:11"
               config:
                 interfaces:
                   - name: eno1
                     type: ethernet
                     state: up
                     ipv4:
                       enabled: false
                     ipv6:
                       enabled: true
                       address:
                         # For SNO sites with static IP addresses, the node-specific,
                         # API and Ingress IPs should all be the same and configured on
                         # the interface
                         - ip: 1111:2222:3333:4444::aaaa:1
                           prefix-length: 64
                 dns-resolver:
                   config:
                     search:
                       - example.com
                     server:
                       - 1111:2222:3333:4444::2
                 routes:
                   config:
                     - destination: ::/0
                       next-hop-interface: eno1
                       next-hop-address: 1111:2222:3333:4444::1
                       table-id: 254

   Note

   Once you have extracted reference CR configuration files from the

   out/extra-manifest

   directory of the

   ztp-site-generate

   container, you can use

   extraManifests.searchPaths

   to include the path to the git directory containing those files. This allows the GitOps ZTP pipeline to apply those CR files during cluster installation. If you configure a

   searchPaths

   directory, the GitOps ZTP pipeline does not fetch manifests from the

   ztp-site-generate

   container during site installation.

5. Generate the Day 0 installation CRs by processing the modified

   SiteConfig

   CR

   site-1-sno.yaml

   by running the following command:

   $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.20 generator install site-1-sno.yaml /output

   Example output

   site-install
   └── site-1-sno
       ├── site-1_agentclusterinstall_example-sno.yaml
       ├── site-1-sno_baremetalhost_example-node1.example.com.yaml
       ├── site-1-sno_clusterdeployment_example-sno.yaml
       ├── site-1-sno_configmap_example-sno.yaml
       ├── site-1-sno_infraenv_example-sno.yaml
       ├── site-1-sno_klusterletaddonconfig_example-sno.yaml
       ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml
       ├── site-1-sno_managedcluster_example-sno.yaml
       ├── site-1-sno_namespace_example-sno.yaml
       └── site-1-sno_nmstateconfig_example-node1.example.com.yaml

6. Optional: Generate just the Day 0

   MachineConfig

   installation CRs for a particular cluster type by processing the reference

   SiteConfig

   CR with the

   -E

   option. For example, run the following commands:

   1. Create an output folder for the

      MachineConfig

      CRs:

      $ mkdir -p ./site-machineconfig

   2. Generate the

      MachineConfig

      installation CRs:

      $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.20 generator install -E site-1-sno.yaml /output

      Example output

      site-machineconfig
      └── site-1-sno
          ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
          ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
          └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml

7. Generate and export the Day 2 configuration CRs using the reference

   PolicyGenerator

   CRs from the previous step. Run the following commands:

   1. Create an output folder for the Day 2 CRs:

      $ mkdir -p ./ref

   2. Generate and export the Day 2 configuration CRs:

      $ podman run -it --rm -v `pwd`/out/argocd/example/acmpolicygenerator:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.20 generator config -N . /output

      The command generates example group and site-specific

      PolicyGenerator

      CRs for single-node OpenShift, three-node clusters, and standard clusters in the

      ./ref

      folder.

      Example output

      ref
       └── customResource
            ├── common
            ├── example-multinode-site
            ├── example-sno
            ├── group-du-3node
            ├── group-du-3node-validator
            │    └── Multiple-validatorCRs
            ├── group-du-sno
            ├── group-du-sno-validator
            ├── group-du-standard
            └── group-du-standard-validator
                 └── Multiple-validatorCRs

8. Use the generated CRs as the basis for the CRs that you use to install the cluster. You apply the installation CRs to the hub cluster as described in "Installing a single managed cluster". The configuration CRs can be applied to the cluster after cluster installation is complete.