Secret error in deploying cluster-api

[ermingpei]

Which jobs are failing: cluster-api

Which tests are failing: cluster-api deployment

Since when has it been failing: I followed this quick start to deploy cluster-api with using kind to create the kubernetes cluster: https://cluster-api.sigs.k8s.io/user/quick-start.html

After ran clusterctl init --core cluster-api:v1.3.2 \ --bootstrap kubeadm:v1.3.2 \ --control-plane kubeadm:v1.3.2 \ --infrastructure openstack:v0.6.4 \ --target-namespace capi-system source env.rc clouds.yaml openstack source /root/capi_envs.sh #other env variables needed

clusterctl generate cluster capi-cluster \ --kubernetes-version v1.25.3 \ --control-plane-machine-count=1 \ --worker-machine-count=2 > capi-cluster.yaml

kubectl apply -f capi-cluster.yaml

then in the control-plane log $ kubectl log capi-kubeadm-control-plane-controller-manager-77c89fc5bc-l6bns -n capi-system, it reads

1 controller.go:185] "Failed to update KubeadmControlPlane Status" err="failed to create remote cluster client: failed to retrieve kubeconfig secret for Cluster default/capi-cluster: secrets \"capi-cluster-kubeconfig\" not found" controller="kubeadmcontrolplane" controllerGroup="controlplane.cluster.x-k8s.io" controllerKind="KubeadmControlPlane" KubeadmControlPlane="default/capi-cluster-control-plane" namespace="default" name="capi-cluster-control-plane" reconcileID=f5e5ac17-67b8-441e-aacd-e4093a7a80f2 Cluster="default/capi-cluster"

Then I tried to replace the name of the secret to capi-cluster-kubeconfig in capi-cluster.yaml file :%s/capi-cluster-cloud-config/capi-cluster-kubeconfig/g

And redeploy the cluster, it reads: 1 controller.go:185] "Failed to update KubeadmControlPlane Status" err="failed to create remote cluster client: failed to retrieve kubeconfig secret for Cluster default/capi-cluster: missing key \"value\" in secret data" controller="kubeadmcontrolplane" controllerGroup="controlplane.cluster.x-k8s.io" controllerKind="KubeadmControlPlane" KubeadmControlPlane="default/capi-cluster-control-plane" namespace="default" name="capi-cluster-control-plane" reconcileID=ececaa9c-e990-4f31-87f8-017b5eba5e85 Cluster="default/capi-cluster"

I don't know what is the correct way to set up the secret.

Testgrid link:

Reason for failure (if possible):

Anything else we need to know: The secret part yaml

---

apiVersion: v1 data: cacert: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0t.... clouds.yaml: Y2xvdWRzOgogIG9wZW5zdGFja.... kind: Secret metadata: labels: clusterctl.cluster.x-k8s.io/move: "true" name: capi-cluster-kubeconfig namespace: default

and the clouds.yaml file

clouds: openstack: identity_api_version: 3 auth: auth_url: https://arbutus.cloud.computecanada.ca:5000/v3 project_name: d... username: e.... password: H... user_domain_name: C... project_domain_name: C... region_name: RegionOne

/kind failing-test

[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[sbueringer]

This secret is generated by CAPI (kcp iirc).

I think there are other issues before e.g. while reconciling the OpenstackCluster

What does clusterctl describe cluster show?

[fabriziopandini]

/triage needs-information

[ermingpei]

Hi Stefan,

It shows:

clusterctl describe cluster capi-cluster

NAME READY SEVERITY REASON SINCE MESSAGE

Cluster/capi-cluster False Warning ScalingUp 20h Scaling up control plane to 1 replicas (actual 0) ├─ClusterInfrastructure - OpenStackCluster/capi-cluster

├─ControlPlane - KubeadmControlPlane/capi-cluster-control-plane False Warning ScalingUp 20h Scaling up control plane to 1 replicas (actual 0) │ └─Machine/capi-cluster-control-plane-s62dh False Info WaitingForInfrastructure 20h 1 of 2 completed

│ └─MachineInfrastructure - OpenStackMachine/capi-cluster-control-plane-bjvgv

└─Workers

└─MachineDeployment/capi-cluster-md-0 False Warning WaitingForAvailableMachines 20h Minimum availability requires 2 replicas, current 0 available └─2 Machines... False Info WaitingForInfrastructure 20h See capi-cluster-md-0-5bfdbcfb6-jm265, capi-cluster-md-0-5bfdbcfb6-shql8

I am wondering where it defines the secret name as CLUSTERNAME-kubeconfig while in the template generated it uses CLUSTERNAME-cloud-config (if this is the same secret it refers to)?

Thanks, Erming

On Thu, Jan 26, 2023 at 11:59 PM Stefan Büringer @.***> wrote:

This secret is generated by CAPI (kcp iirc).

I think there are other issues before e.g. while reconciling the OpenstackCluster

What does clusterctl describe cluster show?

— Reply to this email directly, view it on GitHub https://github.com/kubernetes-sigs/cluster-api/issues/8010#issuecomment-1406099056, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEB5QGPM7E7EXUKBT6OREP3WUNW3VANCNFSM6AAAAAAUH6WWG4 . You are receiving this because you authored the thread.Message ID: @.***>

[ermingpei]

Reading the doc, https://cluster-api.sigs.k8s.io/developer/architecture/controllers/cluster.html?highlight=secret#secrets, it reads: Alternatively can entirely bypass Cluster API generating a kubeconfig entirely if you provide a kubeconfig secret formatted as described below.

Secret name Field name Content

-kubeconfig value base64 encoded kubeconfig I am just wondering in the secret yaml stanze where I could add the "value" field, as it needed?

[killianmuldoon]

I don't think using external secrets is the simplest solution to your problem. This appears to be some issue on the cluster-api-provider-openstack possibly down to the external cloud provider.

You might get more insight if you ask over at that repo, or on the slack channel for cluster-api-provider-openstack.

[killianmuldoon]

/remove-kind failing-test /kind support /triage needs

[k8s-ci-robot]

@killianmuldoon: The label(s) triage/needs cannot be applied, because the repository doesn't have them.

In response to [this](https://github.com/kubernetes-sigs/cluster-api/issues/8010#issuecomment-1407371362): >/remove-kind failing-test >/kind support >/triage needs > > Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[ermingpei]

I have figured out the cause of the problem: I was too rush to check the logs! It takes a while until the creation of the secret (-kubeconfig) so I added sleep 600 to the deployment script before kubectl apply -f .yaml Then it passed. I shouldn't have renamed the secret -cloud-config to -kubeconfig as they are two different secrets. All the trick is just to wait for a while for the boot-strap cluster gets all ready, before creating the overlay cluster.

[fabriziopandini]

Thanks for reporting back @ermingpei, really appreciated! /close

[k8s-ci-robot]

@fabriziopandini: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/cluster-api/issues/8010#issuecomment-1427052313): >Thanks for reporting back @ermingpei, really appreciated! >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.