-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Summary
Investigate whether the core generate-mc bootstrap steps can be decoupled from the Giant Swarm App Platform (app-operator, chart-operator, App/Chart CRDs).
Currently, generate-mc creates a management cluster through these phases:
- Creates bootstrap cluster (Kind locally, vCluster in CI)
- Deploys CAPI and the infrastructure provider
- Deploys the management cluster via Helm
- Pivots CAPI workloads from bootstrap to real cluster
Each of these phases has varying degrees of coupling to the App Platform. This spike should map out those dependencies and determine what it would take to remove them.
Context
The App Platform (app-operator, chart-operator, app-admission-controller, App/Chart CRDs) is deeply woven into the bootstrap process. Key integration points include:
- CAPI deployment (
setup-capi.sh) usesdeploy_app.shhelper which relies on konfigure/Helm patterns tied to the app platform - App CRDs (
setup-app-crds.sh) are installed on the bootstrap cluster - App Platform operators (
setup-app-chart-operator.sh) are deployed on both the bootstrap and the final MC - App catalogs (
setup-app-catalog.sh) are created for app discovery - cluster-apps-operator manages cluster-scoped applications (AWS)
- Default apps can be deployed either integrated into the cluster chart or as separate App CRs via the app platform
The mc-bootstrap revamp (#4180) aims to minimize custom tooling in favor of declarative GitOps. Understanding the App Platform coupling is essential to determine the minimal bootstrap path.
Questions to Answer
- Which
generate-mcsteps have a hard dependency on the App Platform vs. using it as a convenience? - Can CAPI controllers and infrastructure providers be deployed directly via Helm without the app platform layer?
- Can the MC cluster chart (
cluster-aws,cluster-azure, etc.) be deployed without app-operator/chart-operator on the bootstrap cluster? - What is the minimal set of components needed on the bootstrap cluster to create and pivot an MC?
- Are there any ordering constraints that force the App Platform to be present before the pivot?
- What would break downstream (post-pivot GitOps, app-collections) if the bootstrap phase didn't use the App Platform?
Key Files to Investigate
Makefile.custom.mk(lines 418-519) - generate-mc orchestrationscripts/setup-capi.sh- CAPI and provider deploymentscripts/setup-app-crds.sh- App/Chart CRD installationscripts/setup-app-chart-operator.sh- App Platform bootstrapscripts/setup-app-catalog.sh- App catalog creationscripts/deploy-mc.sh- MC deployment via Helmscripts/pivot-mc.sh- CAPI pivot (clusterctl move)scripts/helpers/deploy_app.sh- App deployment helperscripts/deploy-cluster-apps-operator.sh- Cluster apps operator
Expected Outcome
A document or issue comment with:
- A dependency map showing which bootstrap steps require the App Platform and why
- Assessment of feasibility for each decoupling opportunity
- Recommended approach for the minimal bootstrap path
- Risks and trade-offs of decoupling
Parent issue
Part of #4180
Metadata
Metadata
Assignees
Labels
Type
Projects
Status