Add support for consuming nightly release manifests in clusterctl

[cahillsf]

Related to #9797, clusterctl current does not support retrieving the nightly image manifests published to https://storage.googleapis.com/artifacts.k8s-staging-cluster-api.appspot.com/components/...

Specifying the google storage URL as an override for the provider repo kicks back the following:
Error: failed to get provider components for the "cluster-api" provider: failed to get repository client for the CoreProvider with name cluster-api: invalid provider url. Only GitHub and GitLab are supported for "https" schema

Here's the line in the source code where this is thrown:

cluster-api/cmd/clusterctl/client/repository/client.go

If I'm understanding correctly, I believe the solution is to implement a repository_googlestorage.go (or something like that) here: https://github.com/kubernetes-sigs/cluster-api/tree/main/cmd/clusterctl/client/repository and then accept URLs like: https://storage.googleapis.

[cahillsf]

/area clusterctl

[sbueringer]

Thx for opening the issue so we can track this going forward!

/triage accepted

[fabriziopandini]

What is the use case for using nightly images?

I'm asking this because the tricky part here is the fact that a repository for clusterctl not only contains components.yaml files, but it also must contains metadata.yaml and something that provides a notion of "versions".

Adding those notions to a google storage bucket will probably require to first reconsider how we store nightly releases in google cloud, including the notion of version and the upgrade of metadata files, and I would prefer to avoid such complexity if we can. Most important, IMO this will be hardly reusable for any other google storage bucket.

As alternative, if this use case is not frequent or it is automated like our CI, I think it is okay to use options like creating a local repository (or clusterctl overrides).

Might be we can even make it simple to create a local repository with nightly release manifests by doing relatively small changes to https://github.com/kubernetes-sigs/cluster-api/blob/main/cmd/clusterctl/hack/create-local-repository.py

But it really depends on which use case we are aiming to address....

[sbueringer]

Sounds reasonable. I was just thinking about making it easy for folks to use nightly images, e.g. to verify fixes after they merged without requiring a tagged release.

But as far as I know nobody asked for it explicitly.

So fine to not implement it / just have a workaround.

@cahillsf Do you still have the doc that you initially wrote for it? (and can you post it here)

Just sounded relatively complicated / tricky to get right.

[cahillsf]

@cahillsf Do you still have the doc that you initially wrote for it? (and can you post it here)

i think i lost it in my last commit, but my original workaround was using image overrides to override the image tag and pull the nightly images.

will take a look at the local-repository python tool to see if this can help use the full nightly manifests rather than just overriding the images

[sbueringer]

Recovered via GitHub UI :)

<h1> Deploying nightly release images </h1>

Cluster API publishes nightly versions of the project's images from the `main` branch to a `staging` registry that can be deployed in a management cluster using [clusterctl image overrides](../configuration.md#image-overrides).

The tagging convention for the nightly images is `nightly_main_$(shell date +'%Y%m%d')`.  

For example, to deploy the image versions `nightly_main_20231201` from the Cluster API staging repository, add the following `images` override entry to your [clusterctl config file](../configuration.md#clusterctl-configuration-file):

images:
  all:
    tag: nightly_main_20231201
    repository: gcr.io/k8s-staging-cluster-api

I was just hoping overall that there is an easier way with clusterctl to just use a different manifest, then having to replace the images. But then clusterctl is not capable of pulling a manifest from a random URL :)

[fabriziopandini]

I can look into the https://github.com/kubernetes-sigs/cluster-api/blob/main/cmd/clusterctl/hack/create-local-repository.py to see if this can be sorted out easily

[sbueringer]

Thx. I'm fine either way. As mentioned above. If nobody is actually looking for this, we can probably avoid the effort of making this work, documenting and then maintaining it.

[fabriziopandini]

ACK, I will give it a try, if it is only one or two hours of effort, it will be nice to have

[fabriziopandini]

/assign
sending a quick solution for this issue; we can eventually iterate if there is need