Ship CAPI with batteries included

[vincepri]

User Story

As a developer/user/operator I would like to deploy a single Cluster API manager/binary with everything except cloud providers for easier management of Cluster API resources

Detailed Description

[A clear and concise description of what you want to happen.]

Goals

• Ship Cluster API manager including CABPK, and possibly the future control plane manager.
• Deploy all CRDs and resources with a single command.

Non-Goals

• Include infrastructure providers.

/kind feature
/milestone v0.3.0
/priority important-soon

[fabriziopandini]

/assign

[detiber]

If we do this, I would like to make sure that we don't consolidate the controllers for the different "providers" into the same go package, and that we do some level of verification that we aren't importing core logic that external providers do not have access to in the "default" provider implementations.

[ncdc]

+1. We aren't planning on merging all the controllers into a single package. Hopefully that won't be an issue with kubebuilder. If you see any evidence of preferential coding treatment to in-tree providers, definitely raise a concern. We're ok for now, though, given the current state of the repo.

[vincepri]

Within the context of shipping Cluster API with batteries included, I left a comment in the CABPK PR to make sure we can agree on how to move forward. Here is some more detail of what I'd like to see:

• Kubeadm controllers live under /bootstrap/kubeadm/controllers.
• Kubeadm types live under /bootstrap/kubeadm/api.
• No Makefile, Dockerfile, go.mod, CI scripts, hacks.
• CRDs live and get generated with top-level CAPI automation under /config/crd/bases.
• Add the Kubeadm controllers and types to /main.go file, ship it with CAPI.

This favors simplicity and at the same time keeps things separated so it can used as a reference.

[detiber]

@vincepri Personally, I'd like to see the CABPK PR merged as is, and a PR that attempts to do the above while preserving Kubebuilder (for creation of additional types and/or webhooks) and controller-tools generation with a single Makefile.

[vincepri]

@chuckha How do you feel about the above? I can take those action items if you don't have time.

[fabriziopandini]

I'm + 1 with Jason on getting moving with and then iterate simplifying automation
But somehow, we should preserve the ability to work on single pieces and assemble everything at release/package time

[vincepri]

I'm fine to merge the PR, I'd like to make sure we're aligned on the state of the repository after it merges, happy to do the work

[chuckha]

Big +1 on alignment. Let's merge the PR and then get to this point iteratively.

[vincepri]

/assign
/lifecycle active