If you have a device that runs an operating system image that includes MicroShift, you can configure the device to fetch Red Hat Advanced Cluster Management registration manifests with the HTTP Config Provider and auto-register the MicroShift cluster with Red Hat Advanced Cluster Management.

For the HTTP Config Provider parameters, see Configuration from an HTTP server in the Additional resources section.

To apply the same configuration across many devices by using a fleet device template, see Configuring fleets to auto-register MicroShift clusters in the Additional resources section.

Configuring your device

Complete the following steps:

1. Create a file, for example acm-registration-repo.yaml, that contains an HTTP Repository resource for the Red Hat Advanced Cluster Management agent registration API. Replace the placeholders in the following example. For role-based access control (RBAC) and how to obtain values such as the token, follow Importing a managed cluster by using agent registration in the Red Hat Advanced Cluster Management documentation up to, but not including, applying the import manifests on a cluster.

   apiVersion: flightctl.io/v1beta1
   kind: Repository
   metadata:
     name: acm-registration
   spec:
     type: http
     url: https://<agent_registration_host>
     validationSuffix: /agent-registration/crds/v1
     httpConfig:
       ca.crt: <base64_encoded_ca_bundle>
       token: <bearer_token>

2. Create the Repository resource by running the following command:

   flightctl apply -f acm-registration-repo.yaml

3. Verify that the resource has been created and is accessible by Red Hat Edge Manager by running the following command:

   flightctl get repository/acm-registration

4. Create or update a Device resource so that its specification matches the same config order as a fleet device template: acm-crd, acm-import, pull-secret, and apply-acm-manifests. MicroShift must authenticate to the container registries that host the Red Hat Advanced Cluster Management images. If the device already has a suitable pull secret for those registries (for example, at /etc/crio/openshift-pull-secret), omit the pull-secret item from the config list. The apply-acm-manifests hook in the following example waits until the kubeadmin kubeconfig file exists and MicroShift pods are ready before it runs kubectl apply. Use those wait steps when MicroShift might not be running when the hook runs, for example if you apply an operating system image update and this registration configuration together in a single device update. See the following example:

   apiVersion: flightctl.io/v1alpha1
   kind: Device
   metadata:
     name: <device_name>
   spec:
     os:
       image: <your os image>
     config:
       - name: acm-crd
         httpRef:
           filePath: /var/local/acm-import/crd.yaml
           repository: acm-registration
           suffix: /agent-registration/crds/v1
       - name: acm-import
         httpRef:
           filePath: /var/local/acm-import/import.yaml
           repository: acm-registration
           suffix: /agent-registration/manifests/{{.metadata.name}}
       - name: pull-secret
         inline:
           - path: "/etc/crio/openshift-pull-secret"
             content: "{\"auths\":{...}}"
       - name: apply-acm-manifests
         inline:
           - path: "/etc/flightctl/hooks.d/afterupdating/50-acm-registration.yaml"
             content: |
               - run: /usr/bin/bash -c "until [ -f $KUBECONFIG ]; do sleep 1; done"
                 timeout: 5m
                 envVars:
                   KUBECONFIG: /var/lib/microshift/resources/kubeadmin/kubeconfig
               - run: kubectl wait --for=condition=Ready pods --all --all-namespaces --timeout=300s
                 timeout: 5m
                 envVars:
                   KUBECONFIG: /var/lib/microshift/resources/kubeadmin/kubeconfig
               - if:
                 - path: /var/local/acm-import/crd.yaml
                   op: [created]
                 run: kubectl apply -f /var/local/acm-import/crd.yaml
                 envVars:
                   KUBECONFIG: /var/lib/microshift/resources/kubeadmin/kubeconfig
               - if:
                 - path: /var/local/acm-import/import.yaml
                   op: [created]
                 run: kubectl apply -f /var/local/acm-import/import.yaml
                 envVars:
                   KUBECONFIG: /var/lib/microshift/resources/kubeadmin/kubeconfig

   Auto-registration uses the Red Hat Advanced Cluster Management agent registration API: devices fetch the Kubernetes manifests for the klusterlet agent and apply them to MicroShift. The config entries in the previous example do the following:

   • acm-crd uses the HTTP configuration provider to query the agent registration server for manifests that contain the custom resource definition for the Red Hat Advanced Cluster Management klusterlet agent. The Red Hat Edge Manager agent writes those manifests to /var/local/acm-import/crd.yaml on the device.
   • acm-import queries the server for import manifests for a cluster whose name matches the device. The {{.metadata.name}} template variable supplies the device name. The agent writes the returned manifests to /var/local/acm-import/import.yaml.
   • pull-secret adds registry credentials on the device so that MicroShift can pull the Red Hat Advanced Cluster Management agent images. Skip this item if you already provide a suitable pull secret by another method, for example by embedding it in the operating system image or by using another configuration provider.
   • apply-acm-manifests adds an afterupdating lifecycle hook rule file under /etc/flightctl/hooks.d/afterupdating/. The hook runs after the configuration is applied and the crd.yaml and import.yaml files exist; it applies those manifests to MicroShift by using kubectl. For more information, see Device lifecycle hooks in the Additional resources section.
5. Apply the device by running the following command:

   flightctl apply -f <device_file>.yaml

6. If the device is not yet enrolled, approve the enrollment request in the Flight Control web console or CLI. Label behavior differs between the console and the CLI; for more information, see Enrolling devices and Alias and labels during enrollment approval in the Additional resources section.