Overview of promoting a cluster plan
This section covers the "Promote" phase of the cluster plan's lifecycle.
After confirming that the cluster plan provisions as intended, you can extend its availability to a broader audience, such as the development team. To achieve this, adjust the scope of the cluster plan.
We've outlined five scenarios to explain how changing the cluster plan's scope influences who can provision clusters and where, when using a plan.
Scenarios
In each of the scenarios, imagine you have pre-created the following in Wayfinder:
| Stages | Workspaces | Cloud Access (stage-workspace) |
|---|---|---|
| prod | test | prod-test |
| platform | app1Dev | prod-app1Dev |
| development | app2Dev | prod-app2Dev |
| platform-test | ||
| platform-app1Dev1 | ||
| platform-app2Dev | ||
| development-test | ||
| development-app1Dev | ||
| development-app2Dev |
The stage and workspace scope combinations described here require a corresponding Cloud Access configuration with a matching stage and workspace scope. The Cloud Access configuration must be set to "Kubernetes Cluster Provisioning" to ensure Wayfinder has the necessary access and permissions to create clusters in your AWS Account, Azure Subscription, or GCP Project. Without this configuration, cluster creation will not be possible even if the cluster plan scope allows it.
The entries in the table above show that each cloud account, subscription, or project is scoped to a specific stage and workspace combination. We have created 9 distinct Cloud Access configrations to illustrate the different scenarios. However, this configuration can vary in practice. For example, developers typically do not need access to production, so you would avoid configuring cloud access with prod-app1Dev and prod-app2Dev combinations.
For more details about each scenario, see:
- Scenario 1: Control Stage and Workspace Scope - Gradually promote the cluster plan to a wider audience.
- Scenario 2: Control on Workspace Scope - Maintain tight scope on workspace visibility but allow all stages.
- Scenario 3: Control on Stage Scope - Maintain tight scope on stage visibility but allow all workspaces.
- Scenario 4: Inactive, but visible in all workspaces - Keep the plan inactive but allow all workspaces to see it.
- Scenario 5: Inactive and not visible in any workspace - Keep the plan inactive with no visibility anywhere.