clusterctl init fails for k0sproject-k0smotron when GOPROXY=off (v1.10.1)

[kahirokunn]

What steps did you take and what happened?

# Disable Go module proxy
export GOPROXY=off

# 1. No target namespace
clusterctl init --bootstrap k0sproject-k0smotron
# Error:
#   failed to get provider components for the "k0sproject-k0smotron" provider:
#   target namespace can't be defaulted. Please specify a target namespace

# 2. With explicit namespace
clusterctl init --bootstrap k0sproject-k0smotron --target-namespace k0smotron
# Error:
#   invalid provider metadata: version v1.5.2 for the provider
#   k0smotron/bootstrap-k0sproject-k0smotron does not match any release series

If GOPROXY is unset (default https://proxy.golang.org,direct) the same command succeeds:

unset GOPROXY
clusterctl init --bootstrap k0sproject-k0smotron
# → management cluster initialises successfully

What did you expect to happen?

clusterctl init should succeed—or at least fail with a single, clear diagnostic—irrespective of GOPROXY settings, as long as the referenced provider versions exist.

Cluster API version

Binary release v1.10.1
(clusterctl version: v1.10.1)

Heads-up: Building clusterctl from the current main branch does not reproduce the issue because the provider-URL table now points at k0smotron/k0smotron and metadata handling has improved.

Kubernetes version

Client Version: v1.33.1
Kustomize Version: v5.6.0
Server Version: v1.33.1

Anything else you would like to add?

• Root cause is a mix of

  1. Hard-coded URLs in v1.10.1 pointing at the old repo (github.com/k0sproject/k0smotron) which now 404s, and
  2. GOPROXY=off preventing direct-VCS fallback, exposing a secondary issue where the v1.5.2 tag’s metadata.yaml lacks a matching releaseSeries.

Label(s) to be applied

/kind bug
/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]

When I tested the repository change I did not get a 404 (see #12225 (comment))

Taking a step back, looks like what we need here is some sort of documentation about how to change the repository url for a provider (assuming this is a process that can be repeated), because only surfacing the issue on clusterctl messages won't prevent issues for users

[kahirokunn]

When I tested it, I got a 302 instead of a 404.
When I dumped it, it seems that the JSON body output as metadata.yaml when redirecting to GitHub was coming through as is, and it wasn't being handled properly.

[chrischdi]

Issue triage:

Due to above linked PRs are merged, I think this one is done.

/close

[k8s-ci-robot]

@chrischdi: Closing this issue.

In response to this:

Issue triage:

Due to above linked PRs are merged, I think this one is done.

/close

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.