Promote / Publish a Cluster Plan
Cluster plans follow an iterative lifecycle to ensure configurations are continuously updated, validated, and deployed according to the latest standards or workspace requirements. A key part of this lifecycle is the promote process, which ensures a validated cluster plan is available for use and can be deprecated when it's no longer needed.
Understanding the "Promote" phase of a Cluster Plan
After creating a cluster plan or a new version, it starts in a "draft" state. In this state, the plan is not yet available in the scoped workspaces or stages, allowing platform engineers to review and validate it before releasing it for consumption. Once validated, the plan goes through the promotion process to be published for users.
Steps to Premote a Cluster Plan
- Draft State
- When a cluster plan is first created, it remains in a draft state. This ensures that it is not immediately available in the scoped workspaces or stages, giving platform engineers time to make changes and validate the plan. The draft status applies to both new plans and updated versions of existing plans.
- Scope Configuration
- Before promoting the cluster plan, review its scope. The scope defines where the plan will be available (e.g., stage and workspace combinations). Ensure the scope is properly aligned with users' needs. Only workspace users with matching cloud access configurations will be able to access and provision clusters using this plan.
- For detailed guidance on how to set the scope correctly, refer to the scope scenario sections.
- Validate the Plan
- Ensure the cluster plan has been tested against a test cluster and validated to work as expected. Any necessary adjustments should already have been made based on testing outcomes.
- Publish the Plan
- Once the scope is confirmed and the plan validated, it can be promoted to a "published" state. This step makes the cluster plan available for consumption by workspace users.
- In the published state, users can start provisioning clusters according to the configurations set in the plan.
Managing Updated Versions
Cluster plans are immutable once a cluster has been provisioned using them. If updates are needed, such as upgrading packages or changing configurations, a new version of the plan must be created.
- The new version will also begin in a draft state, where it is unavailable for users. Only after validation and promotion will it be available for use.
- Once validated, the updated plan can be published, following the same promotion process, ensuring that users always have access to the latest configurations.
Deprecating a Cluster Plan
In cases where a cluster plan should no longer be used — such as when it provisions clusters with an outdated or unsupported Kubernetes version — the plan can be deprecated.
- Deprecating a cluster plan prevents it from being used for future cluster provisioning while leaving existing clusters unaffected. This ensures that users cannot create new clusters with unsupported or deprecated configurations.
- Deprecated plans will remain visible in the Admin section for auditing or reference purposes, but cannot be used again to provision clusters until republished.
The Continuous Lifecycle of Cluster Plans
This promotion process, including draft, publishing, updating, and deprecation, is part of a continuous lifecycle. Each plan or version goes through validation and promotion, ensuring it is properly managed and made available only when ready for use. This keeps your infrastructure up to date while allowing platform engineers to manage deprecated or unsupported configurations.