ZTP Workflow

As mentioned, Zero Touch Provisioning (ZTP) leverages multiple products or components to deploy OpenShift Container Platform clusters using a GitOps approach. While the workflow starts when the site is connected to the network and ends with the CNF workload deployed and running on the site nodes, it can be logically divided into two different stages: provisioning of the SNO and applying the desired configuration, which in our case is applying the validated RAN DU profile.

The workflow is officially started by creating declarative configurations for the provisioning of your OpenShift clusters. This manifest is described in a custom resource called SiteConfig. Note that, in a disconnected environment, there is a need for a container registry to deliver the OpenShift container images required for the installation. This task can be achieved by using oc-mirror. More information about disconnected environments can be found in Deployment Considerations section.

Once the configuration is created you can push it to the Git repo where Argo CD is continuously looking to pull the new content:

Argo CD pulls the SiteConfig and uses a specific kustomize plugin called siteconfig-generator to transform it into custom resources that are understood by the hub cluster (RHACM/MCE). A SiteConfig contains all the necessary information to provision your node or nodes. Basically, it will create ISO images with the defined configuration that are delivered to the edge nodes to begin the installation process. The images are used to repeatedly provision large numbers of nodes efficiently and quickly, allowing you keep up with requirements from the field for far edge nodes.

In the picture, these resulting manifests are called Cluster Installation CRs, but you can find them detailed in the previous SiteGen section. Finally, the provisioning process starts.

The provisioning process includes installing the host operating system (RHCOS) on a blank server and deploying OpenShift Container Platform. This stage is managed mainly by the Infrastructure Operator. In the previous Infrastructure operator section there is detailed information of the workflow controlled by this piece of software.

Once the clusters are provisioned, the day-2 configuration defined in one or multiple PolicyGenTemplate (PGTs) custom resources will be automatically applied. PolicyGenTemplate custom resource is understood by the ZTP using a specific kustomize plugin called policy-generator. These templates generate Policy CRs on the hub cluster which define the configuration to be applied to the deployed clusters. A Policy CR can be bound to multiple clusters allowing a scalable means to define configuration across a large fleet of clusters. In RAN DU nodes, these policies configure subscriptions for day-two operators, performance tuning, and other necessary platform level configuration.

Notice that if, later on, you want to apply a new configuration or replace an existing configuration you can update the PolicyGenTemplate in Git which will automatically propagate to the Policy CRs on the hub cluster.