Skip to content

Investigate decoupling generate-mc bootstrap from the App Platform #4215

@alex-dabija

Description

@alex-dabija

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:

  1. Creates bootstrap cluster (Kind locally, vCluster in CI)
  2. Deploys CAPI and the infrastructure provider
  3. Deploys the management cluster via Helm
  4. 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) uses deploy_app.sh helper 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

  1. Which generate-mc steps have a hard dependency on the App Platform vs. using it as a convenience?
  2. Can CAPI controllers and infrastructure providers be deployed directly via Helm without the app platform layer?
  3. Can the MC cluster chart (cluster-aws, cluster-azure, etc.) be deployed without app-operator/chart-operator on the bootstrap cluster?
  4. What is the minimal set of components needed on the bootstrap cluster to create and pivot an MC?
  5. Are there any ordering constraints that force the App Platform to be present before the pivot?
  6. 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 orchestration
  • scripts/setup-capi.sh - CAPI and provider deployment
  • scripts/setup-app-crds.sh - App/Chart CRD installation
  • scripts/setup-app-chart-operator.sh - App Platform bootstrap
  • scripts/setup-app-catalog.sh - App catalog creation
  • scripts/deploy-mc.sh - MC deployment via Helm
  • scripts/pivot-mc.sh - CAPI pivot (clusterctl move)
  • scripts/helpers/deploy_app.sh - App deployment helper
  • scripts/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

area/kaasMission: Cloud Native Platform - Self-driving Kubernetes as a Servicekind/spiketeam/phoenixTeam Phoenix

Type

No type

Projects

Status

In Progress ⛏️

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions