clusterctl: dump metadata.yaml at -v=10 to aid debugging

[kahirokunn]

What would you like to be added (User Story)?

As a clusterctl user I would like clusterctl -v=10 to dump the metadata.yaml content for each provider release so that I can understand what is happening under the hood and file accurate GitHub issues when something goes wrong.

Detailed Description

Currently, even with -v=10, clusterctl does not surface enough context during provider download.
When provider metadata is malformed or incompatible, only generic errors are shown, leaving users guessing and preventing well-formed bug reports.

This feature proposes:

• Emitting the raw metadata.yaml content at log level V(10) during download.

Benefits:

• Transparency – users and operators gain immediate insight into what metadata clusterctl is processing.
• Faster debugging – developers can reproduce and diagnose issues from a single log bundle.
• Better issue quality – users can attach the dumped metadata.yaml, reducing back-and-forth.

Anything else you would like to add?

Verbose logs are valuable not only for developers but also for end-users operating clusterctl in CI/CD pipelines or air-gapped environments.
Without this visibility, errors such as “failed to parse metadata” are hard to triage, leading to incomplete or incorrect issue reports.

Label(s) to be applied

/kind feature
/area clusterctl

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determine 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. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[fabriziopandini]

See #12242 (comment)

We also do not use log levels >5 or 6, due to client go noise + it is much cleaner to have in the logs a link to where the metadata file is (and we already have this)

Fetching file="metadata.yaml" provider="cluster-api" type="CoreProvider" version="v1.10.1"
Potential override file searchFile="/Users/xxxx/Library/Application Support/cluster-api/overrides/bootstrap-k0sproject-k0smotron/v1.5.2/metadata.yaml" provider="bootstrap-k0sproject-k0smotron" version="v1.5.2"

Than logging

Dumping metadata.yaml via downloadFilesFromRelease provider="cluster-api" fileName="metadata.yaml"
metadata.yaml content providerID="cluster-api/v1.10.1" content="# maps release series of major.minor to cluster-api contract version\n# the contract version may change between minor or major versions, but *not*\n# b
etween patch versions.\n#\n# update this file only when a new major or minor version is released\napiVersion: clusterctl.cluster.x-k8s.io/v1alpha3\nkind: Metadata\nreleaseSeries:\n  - major: 1\n    minor: 10\n    co
ntract: v1beta1\n  - major: 1\n    minor: 9\n    contract: v1beta1\n  - major: 1\n    minor: 8\n    contract: v1beta1\n  - major: 1\n    minor: 7\n    contract: v1beta1\n  - major: 1\n    minor: 6\n    contract: v1b
eta1\n  - major: 1\n    minor: 5\n    contract: v1beta1\n  - major: 1\n    minor: 4\n    contract: v1beta1\n  - major: 1\n    minor: 3\n    contract: v1beta1\n  - major: 1\n    minor: 2\n    contract: v1beta1\n  - m
ajor: 1\n    minor: 1\n    contract: v1beta1\n  - major: 1\n    minor: 0\n    contract: v1beta1\n"

Which is hardly readable

[kahirokunn]

I see, I understand now.
Thank you very much!