✨ Check CAPI provider latest version daily

[Danil-Grigorev]

• Perform check that CAPIProvider is up-to-date with current latest daily. Longer delay is set to prevent hitting github rate limits.

What this PR does / why we need it:

This change performs daily check for provider upgrades, and performs the actual upgrade automatically, if the CAPIProvider version is not set. If it is set, the version is user managed so we don’t upgrade this automatically.

Once upstream (capi-operator) has a condition to notify about new version availability, this daily check can be changed to rely on the status condition.

This change ensures we don’t leave existing users on older versions of providers.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #673

Special notes for your reviewer:

Checklist:

• squashed commits into logical changes
• includes documentation
• adds unit tests
• adds or updates e2e tests

[salasberryfin]

LGMT but I'm wondering what would happen if a latest version breaks something and user needs to roll back to previous one. Would they need to manually specify a version so this check is not performed?

[alexander-demicev]

In my opinion the default behavior should stay as it is today and automatic updates can be enabled with a separate API field.

[Danil-Grigorev]

@alexander-demicev This can be addressed in the followup pr.

[furkatgofurov7]

Does this try to avoid the need for bumping versions of core CAPI and providers manually (i.e in go.mod)? When CAPI is
released, let's say 1.8.0, not all providers, release the compatible version to that of CAPI. Would that mean we will test CAPI 1.8.0 and CAPI Provider complaint with CAPI 1.7?

[alexander-demicev]

@Danil-Grigorev sure, in that case let's merge this PR after the release, and as @furkatgofurov7 mentioned we would also need to pin e2e suite dependencies if want to test the same CAPI version as now

[alexander-demicev]

@Danil-Grigorev Let's take a bit more time to think about this feature, just to avoid any issues before the release

[Danil-Grigorev]

@alexander-demicev This change is required if #672 is planned to shipped this release. Otherwise users will have to update manually to 1.7.x, and there is a room for error. (Side note: this needs to be documented, that version bump needs to be manual).

[alexander-demicev]

Manual updates after the Turtles upgrade are ok, automatic updates of CAPI providers should be an optional feature

[Danil-Grigorev]

I’m not opposed to optionality of this feature. I think that it should be a part of the followup PR, where it can be decided which providers will have it set by default, which will not, since it is contracting the change of this PR, but I’m of a different opinion about latest behavior, since latests is a moving target, an it needs to be taken this way.

@salasberryfin Users can always specify a different version if they see an issue, or for any other imaginable reason. This PR or any other change should not affect (interfere) with this functionality. We also test this combination of current latest for each provider, so if it happens we need to address it in our CI. Also this supports the need to have every version of the CAPI/provider release to be mirrored, since an issue may force a larger version gap downgrade. + Direct downgrades of major.minor are not supported by the CAPI Operator, only patch versions. This requires the removal of the proxied provider in advance (a detail to add to troubleshooting section of the docs)

@furkatgofurov7 I think it is unrelated to this PR, this has nothing to do with go.mod version bumps. We have an upper cap of provider version, and this is defined by the current version of the clusterctl.yaml config map (CAPI at 1.7.3 there now, this is latest for the next release). I’ll open an issue to address CAPIProvider documentation, functionality and versioning strategy.

[alexander-demicev]

@Danil-Grigorev would you like to make the feature optional in this PR or in a follow-up? We can merge it like it is now if you want to do it in a follow-up

[Danil-Grigorev]

Yes please, I'd like to make a follow up PR @alexander-demicev as already mentioned