|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * edge_computing/ztp-deploying-far-edge-sites.adoc |
| 4 | + |
| 5 | +:_mod-docs-content-type: CONCEPT |
| 6 | +[id="ztp-sno-accelerated-ztp_{context}"] |
| 7 | += Accelerated provisioning of {ztp} |
| 8 | + |
| 9 | +:FeatureName: Accelerated provisioning of {ztp} |
| 10 | +include::snippets/technology-preview.adoc[] |
| 11 | + |
| 12 | +You can reduce the time taken for cluster installation by using accelerated provisioning of {ztp} for {sno}. |
| 13 | +Accelerated ZTP speeds up installation by applying Day 2 manifests derived from policies at an earlier stage. |
| 14 | + |
| 15 | +[IMPORTANT] |
| 16 | +==== |
| 17 | +Accelerated provisioning of {ztp} is supported only when installing {sno} with Assisted Installer. Otherwise this installation method will fail. |
| 18 | +==== |
| 19 | + |
| 20 | +[id="activating-accelerated-ztp_{context}"] |
| 21 | +== Activating accelerated ZTP |
| 22 | + |
| 23 | +You can activate accelerated ZTP using the `spec.clusters.clusterLabels.accelerated-ztp` label, as in the following example: |
| 24 | + |
| 25 | +.Example Accelerated ZTP `SiteConfig` CR. |
| 26 | +[source,yaml] |
| 27 | +---- |
| 28 | +apiVersion: ran.openshift.io/v2 |
| 29 | +kind: SiteConfig |
| 30 | +metadata: |
| 31 | + name: "example-sno" |
| 32 | + namespace: "example-sno" |
| 33 | +spec: |
| 34 | + baseDomain: "example.com" |
| 35 | + pullSecretRef: |
| 36 | + name: "assisted-deployment-pull-secret" |
| 37 | + clusterImageSetNameRef: "openshift-4.10" |
| 38 | + sshPublicKey: "ssh-rsa AAAA..." |
| 39 | + clusters: |
| 40 | + # ... |
| 41 | + clusterLabels: |
| 42 | + common: true |
| 43 | + group-du-sno: "" |
| 44 | + sites : "example-sno" |
| 45 | + accelerated-ztp: full |
| 46 | +
|
| 47 | +---- |
| 48 | + |
| 49 | +You can use `accelerated-ztp: full` to fully automate the accelerated process. |
| 50 | +{ztp} updates the `AgentClusterInstall` resource with a reference to the accelerated {ztp} `ConfigMap`, and includes resources extracted from policies by {cgu-operator}, and accelerated ZTP job manifests. |
| 51 | + |
| 52 | +If you use `accelerated-ztp: partial`, {ztp} does not include the accelerated job manifests, but includes policy-derived objects created during the cluster installation of the following `kind` types: |
| 53 | + |
| 54 | +* `PerformanceProfile.performance.openshift.io` |
| 55 | +* `Tuned.tuned.openshift.io` |
| 56 | +* `Namespace` |
| 57 | +* `CatalogSource.operators.coreos.com` |
| 58 | +* `ContainerRuntimeConfig.machineconfiguration.openshift.io` |
| 59 | + |
| 60 | +This partial acceleration can reduce the number of reboots done by the node when applying resources of the kind `Performance Profile`, `Tuned`, and `ContainerRuntimeConfig`. |
| 61 | +{cgu-operator} installs the Operator subscriptions derived from policies after {rh-rhacm} completes the import of the cluster, following the same flow as standard {ztp}. |
| 62 | + |
| 63 | +The benefits of accelerated ZTP increase with the scale of your deployment. |
| 64 | +Using `accelerated-ztp: full` gives more benefit on a large number of clusters. |
| 65 | +With a smaller number of clusters, the reduction in installation time is less significant. |
| 66 | +Full accelerated ZTP leaves behind a namespace and a completed job on the spoke that need to be manually removed. |
| 67 | + |
| 68 | +One benefit of using `accelerated-ztp: partial` is that you can override the functionality of the on-spoke job if something goes wrong with the stock implementation or if you require a custom functionality. |
| 69 | + |
| 70 | +[id="the-accelerated-ztp-process_{context}"] |
| 71 | +== The accelerated ZTP process |
| 72 | + |
| 73 | +Accelerated ZTP uses an additional `ConfigMap` to create the resources derived from policies on the spoke cluster. |
| 74 | +The standard `ConfigMap` includes manifests that the {ztp} workflow uses to customize cluster installs. |
| 75 | + |
| 76 | +{cgu-operator} detects that the `accelerated-ztp` label is set and then creates a second `ConfigMap`. |
| 77 | +As part of accelerated ZTP, the `SiteConfig` generator adds a reference to that second `ConfigMap` using the naming convention `<spoke-cluster-name>-aztp`. |
| 78 | + |
| 79 | +After {cgu-operator} creates that second `ConfigMap`, it finds all policies bound to the managed cluster and extracts the {ztp} profile information. |
| 80 | +{cgu-operator} adds the {ztp} profile information to the `<spoke-cluster-name>-aztp` `ConfigMap` custom resource (CR) and applies the CR to the hub cluster API. |
0 commit comments