🌱 Standardize api import aliases

[sbueringer]

What this PR does / why we need it:
This PR standardizes our import aliases (follow-up to: #5788 (comment))

Upsides of standardizing aliases:

• Consistent importing, i.e. whenever you see an import alias somewhere in the code you can be sure your using the right package / version of the package
  • So no more cases of the v1alpha4 package being aliased as v1beta1 and vice versa.
• it makes especially the conversion files way more readable if every package just has one alias we're always using
• no more nits on PRs for import aliases of one of the enforced packages
• it should help as an additional validation layer when we're introducing the next api version as we can just adjust the expected aliases in golangci.yaml and the linter will catch a bunch of mistakes for us.

Not sure how it works in other IDEs, but in Intellij you can just write bootstrapv1.<struct-name> and it will automatically import the correct package because it tracks all known aliases. This works better if there is a clear alias=>package mapping.

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 #

[k8s-ci-robot]

@sbueringer: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-cluster-api-e2e-ipv6-main	83d5a61	link	false	/test pull-cluster-api-e2e-ipv6-main

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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/test-infra repository. I understand the commands that are listed here.

[fabriziopandini]

nice one!

[sbueringer]

/reopen

[k8s-ci-robot]

@sbueringer: Failed to re-open PR: state cannot be changed. There are no new commits on the sbueringer:pr-standardize-api-import-aliases branch.

In response to this:

/reopen

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/test-infra repository.

[sbueringer]

Something broke my rebase workflow. I'll open a new PR

[sbueringer]

Okay I just revived that branch/PR instead

/reopen

[k8s-ci-robot]

@sbueringer: Reopened this PR.

In response to this:

/reopen

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/test-infra repository.

[sbueringer]

Rebased and self-reviewed the PR. Should be ready for review now.

[sbueringer]

/assign @fabriziopandini @vincepri

(cc @stmcginnis, might be also interesting for you)

[killianmuldoon]

Thanks for doing this! It should help clarify things.
We should add this as a task for releasing a new API version somewhere too, but that can be outside of this PR.

/lgtm

[enxebre]

should we reserve v1 for real v1 and let the beta imports be consistent e.g bootstrapv1beta1?

[sbueringer]

Hm good question. Up until know we used v1 everywhere (and with everywhere I also mean in a bunch of providers :))

[sbueringer]

I think the main idea behind that is that when we upgrade the version only the import changes and not huge parts of the codebase

[fabriziopandini]

yes. this is for avoiding churn in the codebase at each release and it kind of makes sense if you read it as the last version in the v1 series (or at least that was the original idea)

[fabriziopandini]

/lgtm
I'm definitely +1 to standardize common imports on well know names (whatever they are).
looking for others' opinions.

[sbueringer]

/assign @vincepri
If you've got some time, would be great if you can take a look :)

[enxebre]

nit: clusterexp*?

[sbueringer]

Would be fine for me. I just used the currently most commonly used alias. But I'm not sure which one would be better (same would probably apply to addonsv1 => clusteraddonsv1, too)

On one side having the cluster prefix would be more consistent with infraexp on the other side it's ab it longer

@fabriziopandini WDYT?

[fabriziopandini]

using cluster prefix seems kind of redundant to me, but no strong opinions

[sbueringer]

Similar here.

[enxebre]

/lgtm

[vincepri]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vincepri

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vincepri]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment