Closed mxmxchere closed 1 month ago
Kamaji unfortunately currently lacks of a KamajiControlPlaneTemplate which is needed for the ClusterClass AFAIK
It lacks a KamajiControlPlane that wants to play with openstack in my setup right now in the first place, but yes you are right, the missing clusterclass template resource will become an issue too.
In order to keep the amount of clusterstacks to a minimum, this could be implemented as a flag e.g. kamaji_controlplane
. This feature can then be used in all clusterstacks (openstack, metal3)
In order to keep the amount of clusterstacks to a minimum, this could be implemented as a flag e.g.
kamaji_controlplane
. This feature can then be used in all clusterstacks (openstack, metal3)
Good idea, also KubeVirt seems to be supported https://github.com/clastix/cluster-api-control-plane-provider-kamaji?tab=readme-ov-file#-supported-capi-infrastructure-providers
I created an upstream PR https://github.com/clastix/cluster-api-control-plane-provider-kamaji/pull/107 which adds KamajiControlPlaneTemplate
CRD.
@chess-knight I don't recall exactly what i did when i tested kamaji, but i pushed some files that i found that had a matching timestamp with this issue to: https://github.com/SovereignCloudStack/cluster-stacks/tree/shared-controlplane-tests
Another upstream PR is here https://github.com/clastix/cluster-api-control-plane-provider-kamaji/pull/109
My very first steps/impression: The controller to create so called tenantcontrolplanes (kamajis core-functionality) works so far pretty nicely. The next layer is to create such a tenantcontrolplane via a cluter-API controlplane (kamajicontrolplane) resource. So far i have not been successful in doing that. Observation: when a kamajicontrolplane resource is created alongside with a supported provider (for example hcloud). The resource is taken care of, otherwise the controller ignores it.