Update the ./subscribe/channel.yaml file by changing the spec: pathname to access your the GitHub name for your forked repository, instead of stolostron. This step specifies where the hub cluster retrieves the release images. Your updated content should look similar to the following example:

spec:
  type: Git
  pathname: https://github.com/<forked_content>/acm-hive-openshift-releases.git

Replace forked_content with the path to your forked repository.

To synchronize your list of fast release images after you have cloned the acm-hive-openshift-releases repository, enter the following command to update the fast images:

make subscribe-fast

Note: You can only run this make command when you are using the Linux or MacOS operating system.

After running this command, the list of available fast release images updates with the currently available images in about one minute.

By default, only the fast images are listed. To synchronize and display the stable release images, enter the following command:

make subscribe-stable

Note: You can only run this make command when you are using the Linux or MacOS operating system.

After running this command, the list of available stable release images updates with the currently available images in about 1 minute.

By default, Red Hat Advanced Cluster Management pre-loads a few ClusterImageSets. You can use the following commands to list what is available and remove the defaults.

oc get clusterImageSets
oc delete clusterImageSet <clusterImageSet_NAME>

Note: If you have not disabled the installer-managed automatic updates of the ClusterImageSets by setting the value of disableUpdateClusterImageSets to true in the multiclusterhub resource, any images that you delete are recreated automatically.

Add the mapping between the managed cluster and the disconnected repository with your cluster image sets by completing the following steps that fits your managed cluster:

Modify the clusterImageSet YAML files for the remaining OpenShift Container Platform release images to reference the correct offline repository where you store the images. Your updates should resemble the following example:

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
    name: img4.4.0-rc.6-x86-64
spec:
    releaseImage: IMAGE_REGISTRY_IPADDRESS_or_DNSNAME/REPO_PATH/ocp-release:4.4.0-rc.6-x86_64

Ensure that the images are loaded in the offline image registry that is referenced in the YAML file.

Create each of the clusterImageSets by entering the following command for each YAML file:

oc create -f <clusterImageSet_FILE>

Replace clusterImageSet_FILE with the name of the cluster image set file. For example:

oc create -f img4.9.9-x86_64.yaml

After running this command for each resource you want to add, the list of available release images will be available.

Create the following BareMetalAsset and Secret CR, and save the file as baremetalasset-cr.yaml:

apiVersion: inventory.open-cluster-management.io/v1alpha1
kind: BareMetalAsset
metadata:
  name: <baremetalasset-machine>
  namespace: <baremetalasset-namespace>
spec:
  bmc:
    address: ipmi://<out_of_band_ip>:<port>
    credentialsName: baremetalasset-machine-secret
  bootMACAddress: "00:1B:44:11:3A:B7"
  hardwareProfile: "hardwareProfile"
  role: "<role>"
  clusterName: "<cluster name>"
---
apiVersion: v1
kind: Secret
metadata:
  name: baremetalasset-machine-secret
type: Opaque
data:
  username: <username>
  password: <password>

Run the following command to create the BareMetalAsset CR:

$ oc create -f baremetalasset-cr.yaml

Check that the BareMetalAsset is created successfully:

$ oc get baremetalassets -A

NAMESPACE   		    NAME                              AGE
ocp-example-bm      baremetalasset-machine   			    2m
ocp-example-bm      csv-f24-h27-000-r630-master-1-1   4d21h

Select Import assets, and import the CSV file that contains the bare metal assets data. The CSV file must have the following header columns:

hostName, hostNamespace, bmcAddress, macAddress, role (optional), username, password

Obtain a login token for your hub cluster, and login to the cluster at the command line. For example:

$ oc login --token=<login_token> --server=https://<hub_cluster_api_url>:6443

Modify the following curl command with the details of the bare metal asset that you want to add to the cluster, and run the command.

$ curl --location --request POST '<hub_cluster_api_url>:6443/apis/inventory.open-cluster-management.io/v1alpha1/namespaces/<bare_metal_asset_namespace>/baremetalassets?fieldManager=kubectl-create' \
--header 'Authorization: Bearer <login_token>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "apiVersion": "inventory.open-cluster-management.io/v1alpha1",
    "kind": "BareMetalAsset",
    "metadata": {
        "name": "<baremetalasset_name>",
        "namespace": "<bare_metal_asset_namespace>"
    },
    "spec": {
        "bmc": {
            "address": "ipmi://<ipmi_address>",
            "credentialsName": "<credentials-secret>"
        },
        "bootMACAddress": "<boot_mac_address>",
        "clusterName": "<cluster_name>",
        "hardwareProfile": "hardwareProfile",
        "role": "worker"
    }
}'

On the Clusters page, Click Create cluster.

Note: This procedure is for creating a cluster. If you have an existing cluster that you want to import, see Importing a target managed cluster to the hub cluster for those steps.

Add the details for your cluster:

Enter details about the control plane pool. There are three control plane nodes that are created for your cluster in the control plane pool. The control plane nodes share the management of the cluster activity. The optional information includes the following fields:

Enter details about your worker pools. You can create zero or more worker nodes in a worker pool to run the container workloads for the cluster. They can be in a single worker pool, or distributed across multiple worker pools. If zero worker nodes are specified, the control plane nodes also function as worker nodes. The optional information includes the following fields:

Enter the networking details for your cluster. This information is required. Multiple networks are required for using IPv6.

Add an optional Ansible Automation Template to run either before or after your cluster installs or upgrades.

You can click Add automation template to create a template.

Review your information and optionally customize it.

Select Create to create the cluster.

Note: You do not have to run the kubectl command that is provided with the cluster details to import the cluster. When you create the cluster, it is automatically configured under the management of Red Hat Advanced Cluster Management.

On the Clusters page, Click Create cluster.

Note: This procedure is for creating a cluster. If you have an existing cluster that you want to import, see Importing a target managed cluster to the hub cluster for those steps.

Add the details for your cluster:

Enter details about the control plane pool. There are three control plane nodes that are created for your cluster in the control plane pool. The control plane nodes share the management of the cluster activity. The optional information includes the following fields:

Enter details about your worker pools. You can create zero or more worker nodes in a worker pool to run the container workloads for the cluster. They can be in a single worker pool, or distributed across multiple worker pools. If zero worker nodes are specified, the control plane nodes also function as worker nodes. The optional information includes the following fields:

Enter the networking details for your cluster. This information is required. Multiple networks are required for using IPv6.

Add an optional Ansible Automation Template to run either before or after your cluster installs or upgrades.

You can click Add automation template to create a template.

Review your information and optionally customize it.

Select Create to create the cluster.

Note: You do not have to run the kubectl command that is provided with the cluster details to import the cluster. When you create the cluster, it is automatically configured under the management of Red Hat Advanced Cluster Management.

On the Clusters page, select Create cluster.

Note: This procedure is for creating a cluster. If you have an existing cluster that you want to import, see Importing a target managed cluster to the hub cluster for those steps.

Add the details for your cluster:

Enter details about the control plane pool. There are three control plane nodes that are created for your cluster in the control plane pool. The control plane nodes share the management of the cluster activity. The optional information includes the following fields:

Enter details about your worker pools. You can create zero or more worker nodes in a worker pool to run the container workloads for the cluster. They can be in a single worker pool, or distributed across multiple worker pools. If zero worker nodes are specified, the control plane nodes also function as worker nodes. The optional information includes the following fields:

Enter the networking details for your cluster. This information is required. Multiple networks are required for using IPv6.

Add an optional Ansible Automation Template to run either before or after your cluster installs or upgrades.

You can click Add automation template to create a template.

Review your information and optionally customize it.

Select Create to create the cluster.

Note: You do not have to run the kubectl command that is provided with the cluster details to import the cluster. When you create the cluster, it is automatically configured under the management of Red Hat Advanced Cluster Management.

On the Clusters page, Click Create cluster.

Note: This procedure is for creating a cluster. If you have an existing cluster that you want to import, see Importing a target managed cluster to the hub cluster for those steps.

Add the details for your cluster:

Enter details about the control plane pool. There are three control plane nodes that are created for your cluster in the control plane pool. The control plane nodes share the management of the cluster activity. The required information includes the following fields:

Enter details about your worker pools. You can create zero or more worker nodes in a worker pool to run the container workloads for the cluster. They can be in a single worker pool, or distributed across multiple worker pools. If zero worker nodes are specified, the control plane nodes also function as worker nodes. The information includes the following fields:

Configure the cluster networking options. This information is required. Multiple networks are required for using IPv6.

Add an optional Ansible Automation Template to run either before or after your cluster installs or upgrades.

You can click Add automation template to create a template.

Review your information and optionally customize it.

Select Create to create the cluster.

Note: You do not have to run the kubectl command that is provided with the cluster details to import the cluster. When you create the cluster, it is automatically configured under the management of Red Hat Advanced Cluster Management.

On the Clusters page, click Create cluster.

Note: This procedure is for creating a cluster. If you have an existing cluster that you want to import, see Importing a target managed cluster to the hub cluster for those steps.

Add the details for your cluster:

Enter details about the control plane node. There are three control plane nodes that are created for your cluster in the control plane pool. The control plane nodes share the management of the cluster activity. The optional information includes the following fields:

Enter details about your worker pools. You can create one or more worker nodes in a worker pool to run the container workloads for the cluster. They can be in a single worker pool, or distributed across multiple worker pools. If zero worker nodes are specified, the control plane nodes also function as worker nodes. The optional information includes the following fields:

Enter the networking details for your cluster. You must provide the values for one or more networks for an IPv4 network. For an IPv6 network, you must define more than one network.

Add an optional Ansible Automation Template to run either before or after your cluster installs or upgrades.

You can click Add automation template to create a template.

Review your information and optionally customize it.

Select Create to create the cluster.

Note: You do not have to run the kubectl command that is provided with the cluster details to import the cluster. When you create the cluster, it is automatically configured under the management of Red Hat Advanced Cluster Management.

On the Clusters page, Click Create cluster.

Note: This procedure is for creating a cluster. If you have an existing cluster that you want to import, see Importing a target managed cluster to the hub cluster for those steps.

Add the details for your cluster:

Select your hosts from the list of hosts that are associated with your credential. Select a minimum of three bare metal assets that are on the same bridge networks as the hypervisor.

The list of hosts is compiled from the existing bare metal assets. Ensure that you are running the latest firmware on the bare metal hosts, or the provision might fail. If you do not have any bare metal assets created, then you can create or import them before you continue with the creation process by selecting Import assets. For more information about creating bare metal assets, see Creating and modifying bare metal assets. Alternatively, you can select Disable certificate verification to bypass the requirement.

Configure the cluster networking options. The following tables shows the networking options and their descriptions:

You can add an additional network by clicking Add network. You must have more than one network if you are using IPv6 addresses.

Add an optional Ansible Automation Template to run either before or after your cluster installs or upgrades.

You can click Add automation template to create a template.

Review your information and optionally customize it.

Select Create to create the cluster.

Note: You do not have to run the kubectl command that is provided with the cluster details to import the cluster. When you create the cluster, it is automatically configured under the management of Red Hat Advanced Cluster Management.

Add the details for your cluster:

Review and save your cluster.

Tip: After you review and save the cluster at this point, your cluster is saved as a draft cluster. You can close the creation process and finish the process later by selecting the cluster name on the Clusters page.

Select whether you want to select the hosts yourself, or if you want them to be selected automatically. The number of hosts is based on the number of nodes that you selected. For example, a SNO cluster only requires one host, while a standard three-node cluster requires three hosts.

The locations of the available hosts that meet the requirements for this cluster are displayed in the list of Host locations. For distribution of the hosts and a more high-availability configuration, select multiple locations.

Add the following IP addresses:

Enter the following command to edit the settings for the cluster that you want to hibernate:

oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>

Replace name-of-cluster with the name of the cluster that you want to hibernate.

Replace namespace-of-cluster with the namespace of the cluster that you want to hibernate.

Enter the following command to view the status of the cluster:

oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml

Replace name-of-cluster with the name of the cluster that you want to hibernate.

Replace namespace-of-cluster with the namespace of the cluster that you want to hibernate.

When the process of hibernating the cluster is complete, the value of the type for the cluster is type=Hibernating.

Enter the following command to edit the settings for the cluster:

oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>

Replace name-of-cluster with the name of the cluster that you want to hibernate.

Replace namespace-of-cluster with the namespace of the cluster that you want to hibernate.

Enter the following command to view the status of the cluster:

oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml

Replace name-of-cluster with the name of the cluster that you want to hibernate.

Replace namespace-of-cluster with the namespace of the cluster that you want to hibernate.

When the process of resuming the cluster is complete, the value of the type for the cluster is type=Running.

Optional: Add any Additional labels.

Note: If you import a Red Hat OpenShift Dedicated cluster and do not specify a vendor by adding a label for vendor=OpenShiftDedicated, or if you add a label for vendor=auto-detect, a managed-by=platform label is automatically added to the cluster. You can use this added label to identify the cluster as a Red Hat OpenShift Dedicated cluster and retrieve the Red Hat OpenShift Dedicated clusters as a group.

Select the import mode that you want to use to identify the cluster that you are importing from the following options:

Optional: Configure the Cluster API address that is on the cluster details page by configuring the URL that is displayed in the table when you run the oc get managedcluster command.

Log in to your hub cluster by running the following command:

oc login

Run the following commands on the hub cluster to create the project and namespace: Note: The cluster name that is defined in CLUSTER_NAME is also used as the cluster namespace in the YAML file and commands:

oc new-project ${CLUSTER_NAME}
oc label namespace ${CLUSTER_NAME} cluster.open-cluster-management.io/managedCluster=${CLUSTER_NAME}

Create a file named managed-cluster.yaml with the following example content:

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: ${CLUSTER_NAME}
  labels:
    cloud: auto-detect
    vendor: auto-detect
spec:
  hubAcceptsClient: true

When the values for cloud and vendor are set to auto-detect, Red Hat Advanced Cluster Management detects the cloud and vendor types automatically from the cluster that you are importing. You can optionally replace the values for auto-detect with with the cloud and vendor values for your cluster. See the following example:

cloud: Amazon
vendor: OpenShift

Apply the YAML file to the ManagedCluster resource by entering the following command:

oc apply -f managed-cluster.yaml

Create the auto-import-secret.yaml file in the ${CLUSTER_NAME} namespace.

Validate the JOINED and AVAILABLE status for your imported cluster. Run the following command from the hub cluster:

oc get managedcluster ${CLUSTER_NAME}

Log in to the managed cluster by running the following command on the managed cluster:

oc login

Run the following command to validate the pod status on the cluster that you are importing:

oc get pod -n open-cluster-management-agent

Obtain the klusterlet-crd.yaml file that was generated by the import controller on your hub cluster by running the following command:

oc get secret ${CLUSTER_NAME}-import -n ${CLUSTER_NAME} -o jsonpath={.data.crds\\.yaml} | base64 --decode > klusterlet-crd.yaml

Obtain the import.yaml file that was generated by the import controller on your hub cluster by running the following command:

oc get secret ${CLUSTER_NAME}-import -n ${CLUSTER_NAME} -o jsonpath={.data.import\\.yaml} | base64 --decode > import.yaml

Proceed with the following steps in the cluster that you are importing:

Log in to the managed cluster that you are importing by entering the following command:

oc login

Apply the klusterlet-crd.yaml that you generated in step 1 by running the following command:

oc apply -f klusterlet-crd.yaml

Apply the import.yaml file that you previously generated by running the following command:

oc apply -f import.yaml

Validate JOINED and AVAILABLE status for the cluster that you are importing. From the hub cluster, run the following command:

oc get managedcluster ${CLUSTER_NAME}

Create a YAML file that is similar to the following example:

apiVersion: agent.open-cluster-management.io/v1
kind: KlusterletAddonConfig
metadata:
  name: <cluster_name>
  namespace: <cluster_name>
spec:
  applicationManager:
    enabled: true
  certPolicyController:
    enabled: true
  iamPolicyController:
    enabled: true
  policyController:
    enabled: true
  searchCollector:
    enabled: true

Apply the YAML by running the following command:

oc apply -f klusterlet-addon-config.yaml

The ManagedCluster-Import-Controller will generate a secret named ${CLUSTER_NAME}-import. The ${CLUSTER_NAME}-import secret contains the import.yaml that the user applies to a managed cluster to install klusterlet.

Add-ons are installed after the cluster you are importing is AVAILABLE.

Validate the pod status of add-ons on the cluster you are importing by running the following command:

oc get pod -n open-cluster-management-agent-addon

Create a pull secret in the namespace where you want your cluster to be imported. For these steps, it is myNamespace.

$ kubectl create secret docker-registry myPullSecret \
  --docker-server=<your-registry-server> \
  --docker-username=<my-name> \
  --docker-password=<my-password>

Create a Placement in the namespace that you created.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: myPlacement
  namespace: myNamespace
spec:
  clusterSets:
  - myClusterSet

Create a ManagedClusterSet resource and bind it to your namespace.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ManagedClusterSet
metadata:
  name: myClusterSet

---
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ManagedClusterSetBinding
metadata:
  name: myClusterSet
  namespace: myNamespace
spec:
  clusterSet: myClusterSet

Create the ManagedClusterImageRegistry CRD in your namespace.

apiVersion: imageregistry.open-cluster-management.io/v1alpha1
kind: ManagedClusterImageRegistry
metadata:
  name: myImageRegistry
  namespace: myNamespace
spec:
  placementRef:
    group: cluster.open-cluster-management.io
    resource: placements
    name: myPlacement
  pullSecret:
    name: myPullSecret
  registry: myRegistryAddress

Enter the following command to edit the resource:

kubectl edit klusterletaddonconfigs.agent.open-cluster-management.io <cluster-name> -n <cluster-name>

Select Save to save your changes.

Note: If you move a managed cluster from one managed cluster set to another, you must have the required RBAC permission available on both managed cluster sets.

Ensure that there is an RBAC ClusterRole entry that allows you to create on a virtual subresource of managedclustersets/join. Without this permission, you cannot assign a managed cluster to a ManagedClusterSet.

If this entry does not exist, add it to your yaml file. A sample entry resembles the following content:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: clusterrole1
rules:
  - apiGroups: ["cluster.open-cluster-management.io"]
    resources: ["managedclustersets/join"]
    resourceNames: ["<clusterset1>"]
    verbs: ["create"]

Replace clusterset1 with the name of your ManagedClusterSet.

Note: If you are moving a managed cluster from one ManagedClusterSet to another, you must have that permission available on both managed cluster sets.

Find the definition of the managed cluster in the yaml file. The section of the managed cluster definition where you add a label resembles the following content:

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true

In this example, cluster1 is the name of the managed cluster.

Add a label that specifies the name of the ManagedClusterSet in the format: cluster.open-cluster-management.io/clusterset: clusterset1.

Your code resembles the following example:

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
  labels:
    cluster.open-cluster-management.io/clusterset: clusterset1
spec:
  hubAcceptsClient: true

In this example, cluster1 is the cluster that is added to the managed cluster set names clusterset1.

Note: If the managed cluster was previously assigned to a managed cluster set that was deleted, the managed cluster might have a managed cluster set already specified to a cluster set that does not exist. If so, replace the name with the new one.

On the Manage resource assignments page, select the checkbox for the resources that you want to remove from the cluster set.

This step removes a resource that is already a member of the cluster set, or adds a resource that is not already a member of the cluster set. You can see if the resource is already a member of a cluster set by viewing the details of the managed cluster.

Run the following command to display a list of managed clusters in the managed cluster set:

oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<clusterset1>

Replace clusterset1 with the name of the managed cluster set.

Remove the label from the the yaml entry for the cluster that you want to remove. See the following code for an example of the label:

labels:
   cluster.open-cluster-management.io/clusterset: clusterset1

Select a namespace and a credential.

Set filters to discover relevant clusters.

Create a script file that contains content that resembles the following example:

UPSTREAM_REGISTRY=quay.io
PRODUCT_REPO=openshift-release-dev
RELEASE_NAME=ocp-release
OCP_RELEASE=4.5.2-x86_64
LOCAL_REGISTRY=$(hostname):5000
LOCAL_SECRET_JSON=/path/to/pull/secret

oc adm -a ${LOCAL_SECRET_JSON} release mirror \
--from=${UPSTREAM_REGISTRY}/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
--to=${LOCAL_REGISTRY}/ocp4 \
--to-release-image=${LOCAL_REGISTRY}/ocp4/release:${OCP_RELEASE}

Replace /path/to/pull/secret with the path to your OpenShift Container Platform pull secret.

Wait for the installation of the operator to finish.

Tip: You can check the status of the installation by entering the oc get pods command on your OpenShift Container Platform command line. Verify that the operator is in the running state.

Clone the graph data Git repository by entering the following command:

git clone https://github.com/openshift/cincinnati-graph-data

Create a file that contains the information for your graph data init. You can find this sample Dockerfile in the cincinnati-operator GitHub repository. The contents of the file is shown in the following sample:

FROM registry.access.redhat.com/ubi8/ubi:8.1

RUN curl -L -o cincinnati-graph-data.tar.gz https://github.com/openshift/cincinnati-graph-data/archive/master.tar.gz

RUN mkdir -p /var/lib/cincinnati/graph-data/

CMD exec /bin/bash -c "tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/
cincinnati/graph-data/ --strip-components=1"

In this example:

Run the following commands to build the graph data init container:

podman build -f <path_to_Dockerfile> -t ${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container:latest
podman push ${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container:latest --authfile=/path/to/pull_secret.json

Replace path_to_Dockerfile with the path to the file that you created in the previous step.

Replace ${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container with the path to your local graph data init container.

Replace /path/to/pull_secret with the path to your pull secret file.

Note: You can also replace podman in the commands with docker, if you don’t have podman installed.

Find the OpenShift Container Platform external registry API, which is located in image.config.openshift.io. This is where the external registry CA certificate is stored.

See Configuring additional trust stores for image registry access in the OpenShift Container Platform documentation for more information.

Add your CA certificate under the key updateservice-registry. OpenShift Update Service uses this setting to locate your certificate:

apiVersion: v1
kind: ConfigMap
metadata:
  name: trusted-ca
data:
  updateservice-registry: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

Edit the cluster resource in the image.config.openshift.io API to set the additionalTrustedCA field to the name of the ConfigMap that you created.

oc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"trusted-ca"}}}' --type merge

Replace trusted-ca with the path to your new ConfigMap.

If you do not want to use the default namespace of the operator, which is openshift-cincinnati, create a namespace for your OpenShift Update Service instance:

Paste the contents from your OpenShift Update Service instance. Your YAML instance might resemble the following manifest:

apiVersion: cincinnati.openshift.io/v1beta2
kind: Cincinnati
metadata:
  name: openshift-update-service-instance
  namespace: openshift-cincinnati
spec:
  registry: <registry_host_name>:<port>
  replicas: 1
  repository: ${LOCAL_REGISTRY}/ocp4/release
  graphDataImage: '<host_name>:<port>/cincinnati-graph-data-container'

Replace the spec.registry value with the path to your local disconnected registry for your images.

Replace the spec.graphDataImage value with the path to your graph data init container. Tip: This is the same value that you used when you ran the podman push command to push your graph data init container.

Paste the following YAML content into the window to create a custom policy:

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-pod
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards:
    policy.open-cluster-management.io/categories:
    policy.open-cluster-management.io/controls:
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-pod-sample-nginx-pod
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Pod
                metadata:
                  name: sample-nginx-pod
                  namespace: default
                status:
                  phase: Running
          remediationAction: inform
          severity: low
  remediationAction: enforce
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-pod
  namespace: default
placementRef:
  name: placement-policy-pod
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-pod
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-pod
  namespace: default
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      []  # selects all clusters if not specified

Replace the content inside the objectDefinition section of the template with content that is similar to the following content to add the settings for your ImageContentSourcePolicy:

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: <your-local-mirror-name>
spec:
  repositoryDigestMirrors:
  - mirrors:
    - <your-registry>
    source: registry.redhat.io

Paste the following YAML content into the window to create a custom policy:

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-pod
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards:
    policy.open-cluster-management.io/categories:
    policy.open-cluster-management.io/controls:
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-pod-sample-nginx-pod
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Pod
                metadata:
                  name: sample-nginx-pod
                  namespace: default
                status:
                  phase: Running
          remediationAction: inform
          severity: low
  remediationAction: enforce
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-pod
  namespace: default
placementRef:
  name: placement-policy-pod
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-pod
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-pod
  namespace: default
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      []  # selects all clusters if not specified

Add the following content to the policy:

apiVersion: config.openshift.io/vi
kind: OperatorHub
metadata:
 name: cluster
spec:
 disableAllDefaultSources: true

Add the following content:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: my-operator-catalog
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: <registry_host_name>:<port>/olm/redhat-operators:v1
  displayName: My Operator Catalog
  publisher: grpc

Replace the value of spec.image with the path to your local restricted catalog source image.

From the managed cluster, confirm that the ClusterVersion upstream parameter is currently the default public OpenShift Update Service operand by entering the following command:

oc get clusterversion -o yaml

The returned content might resemble the following content:

apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.4
    upstream: https://api.openshift.com/api/upgrades_info/v1/graph

From the hub cluster, identify the route URL to the OpenShift Update Service operand by entering the following command: oc get routes.

Tip: Note this value for later steps.

Paste the following YAML content into the window to create a custom policy:

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-pod
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards:
    policy.open-cluster-management.io/categories:
    policy.open-cluster-management.io/controls:
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-pod-sample-nginx-pod
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Pod
                metadata:
                  name: sample-nginx-pod
                  namespace: default
                status:
                  phase: Running
          remediationAction: inform
          severity: low
  remediationAction: enforce
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-pod
  namespace: default
placementRef:
  name: placement-policy-pod
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-pod
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-pod
  namespace: default
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      []  # selects all clusters if not specified

Add the following content to policy.spec in the policy section:

apiVersion: config.openshift.io/v1
  kind: ClusterVersion
  metadata:
    name: version
  spec:
    channel: stable-4.4
    upstream: https://example-cincinnati-policy-engine-uri/api/upgrades_info/v1/graph

Replace the value of spec.upstream with the path to your hub cluster OpenShift Update Service operand.

Tip: You can complete the following steps to determine the path to the operand:

In the managed cluster CLI, confirm that the upstream parameter in the ClusterVersion is updated with the local hub cluster OpenShift Update Service URL by entering:

oc get clusterversion -o yaml

Verify that the results resemble the following content:

apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.4
    upstream: https://<hub-cincinnati-uri>/api/upgrades_info/v1/graph

Verify that the optional upgrade paths are available.

Note: No available upgrade versions are shown if the current version is not mirrored into the local image repository.

Compact the etcd history.

Use the backup and restore operator, backupschedule.cluster.open-cluster-management.io and restore.cluster.open-cluster-management.io resources, to create a backupschedule.cluster.open-cluster-management.io resource using the cluster_v1beta1_backupschedule.yaml sample file. See the cluster-backup-operator samples. Run the following command to create a backupschedule.cluster.open-cluster-management.io resource using the cluster_v1beta1_backupschedule.yaml sample file:

kubectl create -n <oadp-operator-ns> -f config/samples/cluster_v1beta1_backupschedule.yaml

Your resource might resemble the following file:

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm
spec:
  maxBackups: 10 # maximum number of backups after which old backups should be removed
  veleroSchedule: 0 */6 * * * # Create a backup every 6 hours
  veleroTtl: 72h # deletes scheduled backups after 72h; optional, if not specified, the maximum default value set by velero is used - 720h

View the following descriptions of the backupschedule.cluster.open-cluster-management.io spec properties:

Check the status of your backupschedule.cluster.open-cluster-management.io resource, which displays the definition for the three schedule.velero.io resources. Run the following command:

oc get bsch -n <oadp-operator-ns>

As a reminder, the restore operation is run on a different hub cluster for restore scenarios. To initiate a restore operation, create a restore.cluster.open-cluster-management.io resource on the hub cluster where you want to restore backups.

You can use the cluster backup and restore operator, backupschedule.cluster.open-cluster-management.io and restore.cluster.open-cluster-management.io resources, to create a backup or restore resource. See the cluster-backup-operator samples.

Run the following command to create a restore.cluster.open-cluster-management.io resource using the cluster_v1beta1_restore.yaml sample file. Be sure to replace the oadp-operator-ns with the namespace name used to install the OADP Operator. The default value for the OADP Operator install namespace is oadp-operator:

kubectl create -n <oadp-operator-ns> -f config/samples/cluster_v1beta1_restore.yaml

Your resource might resemble the following file:

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
spec:
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

View the following description of the three required spec properties for restore.cluster.open-cluster-management.io:

View the Velero Restore resource by running the following command:

oc get restore.velero.io -n <oadp-operator-ns>

View the following YAML examples to restore different types of backed up files: