Update the ./subscription/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: GitHub
  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 stable release images after you have cloned the acm-hive-openshift-releases repository, enter the following command to update the stable images:

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 one minute.

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

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 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, any images that you delete are recreated automatically.

Create clusterImageSets command:

oc create -f <clusterImageSet_FILE>

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

On the Clusters page, select the Provider connections tab.

Existing provider connections are displayed.

Select a namespace for your provider connection from the list.

Tip: Create a namespace specifically to host your provider connections, both for convenience and added security.

On the Clusters page, select the Provider connections tab.

Existing provider connections are displayed.

Select a namespace for your provider connection from the list.

Tip: You can create a namespace specifically to host your provider connections, both for convenience and added security.

Add your Client ID. This value is generated as the appId property when you create a service principal with the following command:

az ad sp create-for-rbac --role Contributor --name <service_principal>

Replace service_principal with the name of your service principal.

Add your Client Secret. This value is generated as the password property when you create a service principal with the following command:

az ad sp create-for-rbac --role Contributor --name <service_principal>

Replace service_principal with the name of your service principal.

Add your Subscription ID. This value is the id property in the output of the following command:

az account show

Add your Tenant ID. This value is the tenantId property in the output of the following command:

az account show

On the Clusters page, select the Provider connections tab.

Existing provider connections are displayed.

Select a namespace for your provider connection from the list.

Add your Google Cloud Platform service account JSON key. Complete the following steps to create one with the correct permissions:

On the Clusters page, select the Provider connections tab.

Existing provider connections are displayed.

Select a namespace for your provider connection from the list.

Tip: Create a namespace specifically to host your provider connections for both convenience and added security.

Add your VMware vCenter root CA certificate.

Create a non-root user (user-name) and provide that user with sudo privileges by running the following commands:

useradd <user-name>
passwd <password>
echo "<user-name> ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/<user-name>
chmod 0440 /etc/sudoers.d/<user-name>

Create an SSH key for the new user by entering the following command:

su - <user-name> -c "ssh-keygen -t rsa -f /home/<user-name>/.ssh/id_rsa -N ''"

Log in as the new user on the provisioner node.

su - <user-name>
[user-name@provisioner ~]$

Use Red Hat Subscription Manager to register the provisioner node by entering the following commands:

sudo subscription-manager register --username=<user-name> --password=<password> --auto-attach
sudo subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms --enable=rhel-8-for-x86_64-baseos-rpms

For more information about Red Hat Subscription Manager, see Using and Configuring Red Hat Subscription Manager in the Red Hat OpenShift Container Platform documentation.

Install required packages by running the following command:

sudo dnf install -y libvirt qemu-kvm mkisofs python3-devel jq ipmitool

Modify the user to add the libvirt group to the newly created user.

sudo usermod --append --groups libvirt <user-name>

Restart firewalld and enable the http service by entering the following commands:

sudo systemctl start firewalld
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --add-port=5000/tcp --zone=libvirt  --permanent
sudo firewall-cmd --add-port=5000/tcp --zone=public   --permanent
sudo firewall-cmd --reload

Start and enable the libvirtd service by entering the following commands:

sudo systemctl start libvirtd
sudo systemctl enable libvirtd --now

Create the default storage pool and start it by entering the following commands:

sudo virsh pool-define-as --name default --type dir --target /var/lib/libvirt/images
sudo virsh pool-start default
sudo virsh pool-autostart default

View the following examples to configure networking:

Reconnect to the provisioner node by using ssh (if required).

# ssh <user-name>@provisioner.<cluster-name>.<domain>

Verify the connection bridges have been correctly created by running the following command:

nmcli con show

Your returned results resemble the following content:

Create a pull-secret.txt file by completing the following steps:

vim pull-secret.txt

On the Clusters page, select the Provider connections tab.

Existing provider connections are displayed.

Select a namespace for your provider connection from the list.

Tip: Create a namespace specifically to host your provider connections, both for convenience and added security.

Add your libvirt URI. The libvirt URI is for your provisioning node that you created for your bootstrap node. Your libvirt URI should resemble the following example:

<qemu+ssh>:://<user-name>@<provision-host.com>/system

For disconnected installations only: Complete the fields in the Configuration for disconnected installation subsection with the required information:

Select Create a 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.

Enter a name for your cluster. This name is used in the hostname of the cluster.

Tip: You can view the yaml content updates as you enter the information in the console by setting the YAML switch to ON.

Configure the Node pools for your cluster.

The node pools define the location and size of the nodes that are used for your cluster.

The Region specifies where the nodes are located geographically. A closer region might provide faster performance, but a more distant region might be more distributed.

Click Create. You can view your cluster details after the create and import process is complete.

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.

Select Actions > Launch to cluster for the cluster that you want to access.

Tip: If you already know the login credentials, you can access the cluster by selecting Actions > Launch to cluster for the cluster that you want to access.

Select Create a 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.

Enter a name for your cluster. This name is used in the hostname of the cluster.

Tip: You can view the yaml content updates as you enter the information in the console by setting the YAML switch to ON.

Configure the Node pools for your cluster.

The node pools define the location and size of the nodes that are used for your cluster.

The Region specifies where the nodes are located geographically. A closer region might provide faster performance, but a more distant region might be more distributed.

Configure the cluster networking options that are necessary.

Enter the base DNS information that you configured for your Azure account. If there is already a base DNS associated with the selected provider connection, that value is populated in that field. You can change the value by overwriting it. See Configuring a custom domain name for an Azure cloud service for more information. This name is used in the hostname of the cluster.

Click Create. You can view your cluster details after the create and import process is complete.

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 for Kubernetes.

Select Actions > Launch to cluster for the cluster that you want to access.

Tip: If you already know the login credentials, you can access the cluster by selecting Actions > Launch to cluster for the cluster that you want to access.

Select Create a 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.

Enter a name for your cluster. This name is used in the hostname of the cluster. There are some restrictions that apply to naming your GCP cluster. These restrictions include not beginning the name with goog or containing a group of letters and numbers that resemble google anywhere in the name. See Bucket naming guidelines for the complete list of restrictions.

Tip: You can view the yaml content updates as you enter the information in the console by setting the YAML switch to ON.

Configure the Node pools for your cluster.

The node pools define the location and size of the nodes that are used for your cluster.

The Region specifies where the nodes are located geographically. A closer region might provide faster performance, but a more distant region might be more distributed.

Configure the cluster networking options that are necessary.

Enter the base DNS information that you configured for your Google Cloud Platform account. If there is already a base DNS that is associated with the selected provider connection, that value is populated in that field. You can change the value by overwriting it. See Setting up a custom domain for more information. This name is used in the hostname of the cluster.

Select Actions > Launch to cluster for the cluster that you want to access.

Tip: If you already know the login credentials, you can access the cluster by selecting Actions > Launch to cluster for the cluster that you want to access.

Select Create a 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.

Enter a name for your cluster. This name is used in the hostname of the cluster.

Note: This value must match the name that you used to create the DNS records listed in the provider connection prerequisites section.

Tip: You can view the yaml content updates as you enter the information in the console by setting the YAML switch to ON.

Configure the Node pools for your cluster.

The node pools define the location and size of the nodes that are used for your cluster.

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.

Configure the cluster networking options, which are shown in the following list:

Click Create. You can view your cluster details after the create and import process is complete.

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

If you do not know the log in credentials

Select Actions > Launch to cluster for the cluster that you want to access.

Tip: If you already know the login credentials, you can access the cluster by selecting Actions > Launch to cluster for the cluster that you want to access.

Select Create a 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.

Enter a name for your cluster. For a bare metal cluster, this name cannot be an arbitrary name. It is associated with the cluster URL. Make sure that the cluster name that you use is consistent with your DNS and network setup.

Tip: You can view the yaml content updates as you enter the information in the console by setting the YAML switch to ON.

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

The list of hosts is compiled from the existing Bare Metal Assets. If you do not have any Bare Metal Assets created, then you can create or import them before you continue with the creation process. Alternatively, you can select Disable certificate verification to bypass the requirement.

Configure the cluster networking options.

Click Create. You can view your cluster details after the create and import process is complete.

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 for Kubernetes.

Select Actions > Launch to cluster for the cluster that you want to access.

Tip: If you already know the login credentials, you can access the cluster by selecting Actions > Launch to cluster for the cluster that you want to access.

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.

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.

In the Import an existing cluster window, select Copy command to copy the generated command and token to the clipboard.

Important: The command contains pull secret information that is copied to each of the imported clusters. Anyone who can access the imported clusters can also view the pull secret information. Consider creating a secondary pull secret at https://cloud.redhat.com/ or create a service account to protect your personal credentials. See Using image pull secrets or Understanding and creating service accounts for more information about pull secrets.

For the Red Hat OpenShift Dedicated environment only Complete the following steps:

For cluster imports that are not in the Red OpenShift Dedicated environment Complete the following steps:

Log in to your hub cluster. Run the following command:

oc login

Run the following command on the hub cluster to create the namespace. Note: The cluster name that is defined in <cluster_name> is also used as the cluster namespace in the .yaml file file and commands:

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

Edit the example ManagedCluster with the following sample of YAML:

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

Apply the YAML file with the following command:

oc apply -f managed-cluster.yaml

Create the klusterlet addon configuration file. Enter the following example YAML:

apiVersion: agent.open-cluster-management.io/v1
kind: KlusterletAddonConfig
metadata:
  name: <cluster_name>
  namespace: <cluster_name>
spec:
  clusterName: <cluster_name>
  clusterNamespace: <cluster_name>
  applicationManager:
    enabled: true
  certPolicyController:
    enabled: true
  clusterLabels:
    cloud: auto-detect
    vendor: auto-detect
  iamPolicyController:
    enabled: true
  policyController:
    enabled: true
  searchCollector:
    enabled: true
  version: 2.2.0

Apply the YAML. Run the following command:

oc apply -f klusterlet-addon-config.yaml

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.

Obtain the klusterlet-crd.yaml that was generated by the managed cluster import controller.

Run 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 that was generated by the managed cluster import controller. Run the following command:

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

Apply the klusterlet-crd.yaml that was generated in step 1. Run the following command:

kubectl apply -f klusterlet-crd.yaml

Apply the import.yaml file that was generated in step 2. Run the following command:

kubectl apply -f import.yaml

Validate the pod status on the target managed cluster. Run the following command:

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

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

kubectl get managedcluster ${CLUSTER_NAME}

Addons will be installed after the managed cluster is AVAILABLE. Validate the pod status of addons on the target managed cluster. Run the following command:

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

Enter the following command to edit the resource:

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

Create the inbound and outbound firewall rules on your Google Cloud Platform to open the IPsec IKE (by default 500/UDP) and NAT traversal ports (by default 4500/UDP) to enable Submariner communication:

$ gcloud compute firewall-rules create <name> --network=<network-name> --allow=udp:<ipsec-port> --direction=IN
$ gcloud compute firewall-rules create <rule-name> --network=<network-name> --allow=udp:<ipsec-port>  --direction=OUT

Replace rule-name with your rule name.

Replace network-name with your Google Cloud Platform cluster network name.

Replace ipsec-port with your IPsec port.

Create the inbound and outbound firewall rules on your Google Cloud Platform to open the 4800/UDP port to encapsulate Pod traffic from the worker and master nodes to the Submariner Gateway nodes:

$ gcloud compute firewall-rules create <name> --network=<network-name> --allow=udp:4800 --direction=IN
$ gcloud compute firewall-rules create <name> --network=<network-name> --allow=udp:4800 --direction=OUT

Replace name with your rule name.

Replace network-name with your Google Cloud Platform cluster network name.

Create the inbound and outbound firewall rules on your Google Cloud Platform to open the 8080/TCP port to export metrics service from the Submariner Gateway nodes:

$ gcloud compute firewall-rules create <name> --network=<network-name> --allow=tcp:8080 --direction=IN
$ gcloud compute firewall-rules create <name> --network=<network-name> --allow=tcp:8080 --direction=OUT

Replace name with your rule name.

Replace network-name with your Google Cloud Platform cluster network name.

Create the inbound and outbound firewall rules on your Microsoft Azure environment to open the IP security IKE (by default 500/UDP) and NAT traversal ports (by default 4500/UDP) to enable Submariner communication:

# create inbound nat rule
$ az network lb inbound-nat-rule create --lb-name <lb-name> \
--resource-group <res-group> \
--name <name> \
--protocol Udp --frontend-port <ipsec-port> \
--backend-port <ipsec-port> \
--frontend-ip-name <frontend-ip-name>

# add your vm network interface to the created inbound nat rule
$ az network nic ip-config inbound-nat-rule add \
--lb-name <lb-name> --resource-group <res-group> \
--inbound-nat-rule <nat-name> \
--nic-name <nic-name> --ip-config-name <pipConfig>

Replace lb-name with your load balancer name.

Replace res-group with your resource group name.

Replace nat-name with your load balancing inbound NAT rule name.

Replace ipsec-port with your IPsec port.

Replace pipConfig with your cluster frontend IP configuration name.

Replace nic-name with your network interface card (NIC) name.

Create one load balancing inbound NAT rules to forward Submariner gateway metrics service request:

# create inbound nat rule
$ az network lb inbound-nat-rule create --lb-name <lb-name> \
--resource-group <res-group> \
--name <name> \
--protocol Tcp --frontend-port 8080 --backend-port 8080 \
--frontend-ip-name <frontend-ip-name>

# add your vm network interface to the created inbound nat rule
$ az network nic ip-config inbound-nat-rule add \
--lb-name <lb-name> --resource-group <res-group> \
--inbound-nat-rule <nat-name> \
--nic-name <nic-name> --ip-config-name <pipConfig>

Replace lb-name with your load balancer name.

Replace res-group with your resource group name.

Replace nat-name with your load balancing inbound NAT rule name.

Replace pipConfig with your cluster frontend IP configuration name.

Replace nic-name with your network interface card (NIC) name.

Create network security groups {NSG) security rules on your Azure to open IPsec IKE (by default 500/UDP) and NAT traversal ports (by default 4500/UDP) for Submariner:

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Inbound --access Allow \
--protocol Udp --destination-port-ranges <ipsec-port>

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Outbound --access Allow \
--protocol Udp --destination-port-ranges <ipsec-port>

Replace res-group with your resource group name.

Replace nsg-name with your NSG name.

Replace priority with your rule priority.

Replace name with your rule name.

Replace ipsec-port with your IPsec port.

Create the NSG rules to open 4800/UDP port to encapsulate pod traffic from the worker and master nodes to the Submariner Gateway nodes:

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Inbound --access Allow \
--protocol Udp --destination-port-ranges 4800 \

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Outbound --access Allow \
--protocol Udp --destination-port-ranges 4800

Replace res-group with your resource group name.

Replace nsg-name with your NSG name.

Replace priority with your rule priority.

Replace name with your rule name.

Create the NSG rules to open 8080/TCP port to export metrics service from the Submariner Gateway nodes:

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Inbound --access Allow \
--protocol Tcp --destination-port-ranges 8080 \

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Outbound --access Allow \
--protocol Udp --destination-port-ranges 8080

Replace res-group with your resource group name.

Replace nsg-name with your NSG name.

Replace priority with your rule priority.

Replace name with your rule name.

Log on to your hub cluster with cluster administrator permissions.

For AWS clusters that were created by Red Hat Advanced Cluster Management for Kubernetes, create a file called submarinerconfig.yaml with the following SubmarinerConfig content:

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
  name: submariner
  namespace: <your-cluster-namespace>
spec:
  credentialsSecret:
    name: <your-cluster-name>-aws-creds
  subscriptionConfig:
    channel: alpha
    startingCSV: submariner.v0.8.1

For AWS clusters that were created by OpenShift Container Platform but imported into Red Hat Advanced Cluster Management, create the aws-cloud-credentials.

Apply the SubmarinerConfig resource to the managed cluster namespace on the hub cluster by entering the following command:

oc apply -f submarinerconfig.yaml

Create a ManagedClusterSet on the hub cluster.

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ManagedClusterSet
metadata:
  name: my-clusterset

Add the managed clusters to the ManagedClusterSet by entering the following command:

oc label managedclusters <managedcluster-name> "cluster.open-cluster-management.io/clusterset=<ManagedClusterSet-name>" --overwrite

Run the following command to allow Red Hat Advanced Cluster Management to automatically deploy Submariner:app-name:

oc label managedclusters <managedcluster-name> "cluster.open-cluster-management.io/submariner-agent=true" --overwrite

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 cincinnati-registry. OpenShift Update Service uses this setting to locate your certificate:

apiVersion: v1
kind: ConfigMap
metadata:
  name: trusted-ca
data:
  cincinnati-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/v1beta1
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: ImageContentSourcePolicy
spec:
  repositoryDigestMirrors:
  - mirrors:
    - <path-to-local-mirror>
    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.