You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This provider generates a kubeconfig secret with the name <cluster>-admin-kubeconfig, with the data keys super-admin.conf etc.
However, other providers create an admin level kubeconfig secret with the name: <cluster>-kubeconfig with the kubeconfig stored in a data key named value.
This is documented here: https://cluster-api.sigs.k8s.io/developer/architecture/controllers/cluster#secrets
It would be great if the kamaji provided matched the existing pattern, so external operators and tools could work seamlessly.
For example, after creating a Kamaji CAPI cluster, the clusterctl get kubeconfig ... command fails because the secret is not in the expected format.
The text was updated successfully, but these errors were encountered:
NAME NAMESPACE TYPE CURRENT VERSION NEXT VERSION
bootstrap-kubeadm capi-kubeadm-bootstrap-system BootstrapProvider v1.7.3 v1.7.4
control-plane-kamaji kamaji-system ControlPlaneProvider v0.10.1 Already up to date
control-plane-kubeadm capi-kubeadm-control-plane-system ControlPlaneProvider v1.7.3 v1.7.4
cluster-api capi-system CoreProvider v1.7.4 Already up to date
infrastructure-kubevirt capk-system InfrastructureProvider v0.1.8 Already up to date
My current clusters:
$: kubectl get clusters
NAME CLUSTERCLASS PHASE AGE VERSION
capi-quickstart Provisioned 4m22s
Retrieving the kubeconfig seems fine to me:
$: clusterctl get kubeconfig capi-quickstart | wc -l
sigs.k8s.io/cluster-api
20
I suspect something is related to #92, it would be great if you could provide a detailed report on how to reproducing.
Infrastructure providers are not important, here, since it's just a matter of how we replicate Cluster API resources.
This provider generates a kubeconfig secret with the name
<cluster>-admin-kubeconfig
, with the data keyssuper-admin.conf
etc.However, other providers create an admin level
kubeconfig
secret with the name:<cluster>-kubeconfig
with the kubeconfig stored in a data key namedvalue
.This is documented here: https://cluster-api.sigs.k8s.io/developer/architecture/controllers/cluster#secrets
It would be great if the kamaji provided matched the existing pattern, so external operators and tools could work seamlessly.
For example, after creating a Kamaji CAPI cluster, the
clusterctl get kubeconfig ...
command fails because the secret is not in the expected format.The text was updated successfully, but these errors were encountered: