clusterctl generate provider should return early if working with incompatible provider versions

[ykakarap]

User Story

As a user when I run clusterctl generate provider on a version of a provider that is incompatible I want it to return early with an error messages that says that the version is incompatible with the version of clusterctl.

Detailed Description

Ref: #5851 (comment) for more details.

Anything else you would like to add:

[Miscellaneous information that will assist in solving the issue.]

/kind feature
/area clusterctl

[fabriziopandini]

/milestone v1.1

[sbueringer]

+1, Afaik we already have a similar logic for clusterctl init

[tharun208]

@ykakarap I like to work on this

[sbueringer]

@tharun208 Great! Feel free to assign yourself the issue with /assign

[tharun208]

sure, thanks and can you help me with this issue, as this is going to be my first PR for cluster-api.

[tharun208]

/assign

[ykakarap]

@tharun208 Thanks for offering to work on the issue. Later, I will add some details here that should help you get started.

[ykakarap]

@tharun208 Here are some details that should help you get started:

The generate provider command directly calls c.GetProviderComponents. We want to add a step to check if the version used are compatible before getting the provider components.

I think you can start with adding a GenerateProvider to clusterctlClient (and the corresponding interface) that takes as input providerName, providerType and options client.ComponentsOptions. This function should perform a check to validate that the input provider version is compatible with the version of clusterctl and after it passed the validation it should call GetProviderComponents as previously being called.

Checking compatibility:
A provider version is considered compatible if it matches the contract version of clusterctl. To fetch the contract version of the provider you can do the following:

// Get the providers metadata.
configRepository, err := c.configClient.Providers().Get(providerName, provider.GetProviderType())
if err != nil {
	return "", err
}
providerRepository, err := c.repositoryClientFactory(configRepository, c.configClient)
if err != nil {
	return "", err
}
latestMetadata, err := providerRepository.Metadata(providerVersion).Get()
if err != nil {
	return "", err
}
// Gets the contract for the current release.
currentVersion, err := version.ParseSemantic(providerVersion)
if err != nil {
	return "", errors.Wrapf(err, "failed to parse current version for the %s provider", providerName)
}
releaseSeries := latestMetadata.GetReleaseSeriesForVersion(currentVersion)
if releaseSeries.Contract != clusterv1.GroupVersion.Version {
	return "", errors.Errorf("current version of clusterctl is only compatible with %s providers, detected %s for provider %s", clusterv1.GroupVersion.Version, releaseSeries.Contract, provider.ManifestLabel())
}

Note: Please adjust the returns in the above example as needed for the function.
Ref here for an example of checking contract.

You can use parseProviderName and the DefaultVersion function of the repository client to compute the version of the input provider.

If the contracts match then we can consider that the version of the provider is compatible with the version of clusterctl. Once validated then you can go ahead and call c.GetProviderComponents(providerName, providerType, options) and print the output as being done previously.

I hope this information is helpful for you to get started on this issue.

Please feel free to reach out if you have any questions. 🙂

[tharun208]

thank you much. will look into this

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ykakarap]

/remove-lifecycle stale

[fabriziopandini]

/triage accepted