Support for CAPL (Cluster API Provider Linode)

[aamoyel]

Hello :)
After a try with CAPI and Linode, we saw that Kamaji does not work with CAPL (Linode).
What's the requirements to support a new provider ?

[prometherion]

👋🏻 the main requirement to support further infrastructure providers is the ability to wait for an external allocation of the Kubernetes API Server Load Balancer which Kamaji does.

I looked at CAPL and it doesn't support this, the first step would be engaging the CAPL community, explaining the goal, and finding a consensus.

If you'd like to take care of this @aamoyel I'll be happy to give you some support.

[guilhem]

Hi @prometherion
I'm working for linode, I will give the information to the team in charge of CAPL :)
thank you

[prometherion]

Thanks, just a friendly reminder we do also have a Slack workspace channel hosted on the Kubernetes one, #kamaji.

[aamoyel]

Thx for your explanations :) .
It might be interesting for @guilhem (actually working on Linode Kubernetes Engine and with the CAPL team).

[prometherion]

Just a small update, another user reported this enhancement introduced with CAPI v1.8 such as the ControlPlaneEndpoint support.

According to the design:

A Control Plane controller implementation must either supply a controlPlaneEndpoint (via its own spec.controlPlaneEndpoint field), or rely on spec.controlPlaneEndpoint in its parent Cluster object.

As Kamaji we could populate the endpoint with the provided IP: the CAPL provider would need to extract that information from the ControlPlane provider rather than creating a LoadBalancer for the VMs.

[aamoyel]

This PR was merge recently. Thx for this update too :)
linode/cluster-api-provider-linode#511

[prometherion]

Great, ball is in our court, then!

I'll align the Kamaji Control Plane Provider to expose that information such as CAPIv1.8 contract requires.

[guilhem]

@prometherion concerning this:

An infrastructureCluster controller is expected to either supply a controlPlaneEndpoint (via its own spec.controlPlaneEndpoint field),
or rely on spec.controlPlaneEndpoint in its parent Cluster object.

If an endpoint is not provided, the implementer should exit reconciliation until it sees cluster.spec.controlPlaneEndpoint populated.

there is too much "or", "should", "expect" 😅

on infrastucture cluster provider, do we have to populate spec.controlPlaneEndpoint only if parent cluster don't have one?

[prometherion]

According to the changes introduced in CAPL and linked in this discussion, the Load Balancer must be marked as external and wait for user input in the Infrastructure Cluster.

With the v1.8 feature, we could expose the Control Plane address directly from our KamajiControlPlane resource, so it would be something as:

• try from Control Plane implementation
• fallback to Infrastructure Cluster

[prometherion]

JFI the v0.12.0 release is offering support for the ControlPlaneEndpoint field in the KamajiControlPlane instance.

Wondering if this implementation sounds good to you, and if that's the case, happy to whitelist the Linode CAPI implementation!