Critical Add-ons
Previously, users were facing issues if the Blueprint synchronization fails, it leads to a cluster entering a bad state, preventing users from performing any cluster operations.
Users now have the option to designate add-ons as critical or non-critical when creating a blueprint. To set specific add-ons as critical, users can select the required addons and enable the Critical option. By default, all add-ons are non-critical except for "v2 infra" and "edge client". These two add-ons are predefined as critical, and users cannot modify their criticality. All other managed and custom add-ons are non-critical by default, but users have the flexibility to mark them as critical if needed.
The below matrix presents deployment methods of Blueprint with critical add-ons: Interactive UI, Declarative RCTL commands, API-driven automation, GitOps System Sync, and Terraform.
Did you know ?
Blueprints with critical add-ons can be managed using different methods:
Managed Add-Ons Criticality
Custom Add-Ons Criticality
When the Blueprint is ready for deployment to the cluster, if non-critical add-ons fail, the cluster operations proceed, and the Blueprint synchronization status is marked as "Partial Success". This allows the cluster to remain active for any workload or day 2 operations, enabling users to perform actions on the clusters.
However, if critical add-ons fail, the Blueprint synchronization also fails, prohibiting users from performing any actions on the clusters until the issue with critical add-ons is resolved.
Blueprint Sync Status Determination¶
| Cluster Status | Description |
|---|---|
| SUCCESS | If all critical and non-critical add-ons are deployed successfully |
| FAILURE | If any of the critical custom add-ons or managed components fail to deploy |
| PARTIAL SUCCESS | If any of the non-critical custom add-ons fail to deploy successfully, all critical add-ons are deployed successfully |
- If the BLUEPRINT STATUS is PARTIAL SUCCESS, operations on the cluster should continue
- Users are permitted to enable or disable the criticality of add-ons on Day 2
UI Visibility¶
The add-ons that encounter deployment failures is accompanied by an explanation of the failure reason. This enhancement aims to improve user experience by providing clear and immediate feedback on the status of add-ons.
Here is an example where one of the non-critical add-ons failed to deploy, resulting in a Partial Success status, as the other add-ons were successfully deployed
When creating a custom Blueprint with the Golden Blueprint as a base, the addon criticality settings of the Golden Blueprint take precedence, and the criticality settings of the custom Blueprint are ignored.
RCTL¶
Include the below parameters in the Blueprint configuration spec to create a blueprint with critical add-ons.
componentsCriticality:
- name: demo-addon
- name: addon-helm
Refer to this page for the detailed configuration specification.