⚠ Split Helm chart into operator and providers charts

[kahirokunn]

Fixes: #534

What type of PR is this?

/kind bug

What this PR does / why we need it:

This PR fixes the flaky Helm installation issue where provider Custom Resources fail to install due to webhook validation errors. The root cause is that provider CRs are being applied at the same time as the operator deployment, before the webhook service is ready.

Problem:
When installing the cluster-api-operator Helm chart, users frequently encounter errors like:

Error: failed post-install: warning: Hook post-install cluster-api-operator/templates/core-conditions.yaml failed: 1 error occurred:
        * Internal error occurred: failed calling webhook "vcoreprovider.kb.io": failed to call webhook: Post "https://capi-operator-webhook-service.cluster-api-operator-docker.svc:443/mutate-operator-cluster-x-k8s-io-v1alpha2-coreprovider?timeout=10s": no endpoints available for service "capi-operator-webhook-service"

Solution:
Split the Helm chart into two separate charts:

1. cluster-api-operator - Contains only the operator deployment and its resources
2. cluster-api-operator-providers - Contains all provider Custom Resources

This ensures the operator is fully running before any provider CRs are applied.

Which issue(s) this PR fixes:

Fixes #[issue-number]

Special notes for your reviewer:

The installation process now requires two steps:

# 1. Install the operator
helm install capi-operator ./cluster-api-operator --namespace capi-operator-system --create-namespace

# 2. Wait for operator to be ready
kubectl wait --for=condition=ready pod -l app=capi-operator -n capi-operator-system --timeout=300s

# 3. Install provider CRs
helm install capi-providers ./cluster-api-operator-providers --namespace capi-operator-system

Release note:

BREAKING CHANGE: The cluster-api-operator Helm chart has been split into two charts to fix webhook validation errors during installation. Users must now install `cluster-api-operator` first, wait for it to be ready, then install `cluster-api-operator-providers`.

Release Strategy and Migration Plan

To minimize the impact on existing users, we propose a phased rollout approach:

Phase 1: Introduce the new chart (Current PR)

• Release only the new cluster-api-operator-providers chart
• Keep the existing cluster-api-operator chart unchanged for backward compatibility
• Users can opt-in to the new architecture when ready

Phase 2: Migration period (Future release)

• Add deprecation warnings to the existing chart
• Provide comprehensive migration documentation
• Announce the breaking change timeline in release notes

Phase 3: Breaking change implementation (Future major release)

• Remove provider CR templates from the original cluster-api-operator chart
• Make the two-chart installation the standard approach
• Provide automated migration tools where possible

This strategy allows users to migrate at their own pace while ensuring the webhook validation issue is resolved for new installations immediately.

[netlify]

✅ Deploy Preview for kubernetes-sigs-cluster-api-operator ready!

Name	Link
🔨 Latest commit	18080c7
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-cluster-api-operator/deploys/685a469bd9f4aa0008729943
😎 Deploy Preview	https://deploy-preview-832--kubernetes-sigs-cluster-api-operator.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign alexander-demicev for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kahirokunn]

Hi @dtzar and @furkatgofurov7,

When you have a moment, could you please review ?

This update splits the chart into operator and provider components, ensuring the operator’s webhook is fully ready before provider CRs are applied. As a result, the no endpoints available for service "capi-operator-webhook-service" validation error has been resolved.

Also, since this PR would result in a breaking change, I think it would be best to either create a new helm chart and gradually migrate to it, or continue to use both. I would appreciate your feedback on this as well.

Thank you for your time and feedback.

Best regards,
@kahirokunn

[k8s-ci-robot]

@kahirokunn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-cluster-api-operator-verify-main	18080c7	link	true	/test pull-cluster-api-operator-verify-main
pull-cluster-api-operator-e2e-main	18080c7	link	true	/test pull-cluster-api-operator-e2e-main

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.