🌱 Prepare main branch for v1.6 development

[furkatgofurov7]

What this PR does / why we need it:
This PR prepares the main branch for development.

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

[furkatgofurov7]

/test ?

[k8s-ci-robot]

@furkatgofurov7: The following commands are available to trigger required jobs:

• /test pull-cluster-api-build-main
• /test pull-cluster-api-e2e-main
• /test pull-cluster-api-test-main
• /test pull-cluster-api-verify-main

The following commands are available to trigger optional jobs:

• /test pull-cluster-api-apidiff-main
• /test pull-cluster-api-e2e-full-dualstack-and-ipv6-main
• /test pull-cluster-api-e2e-full-main
• /test pull-cluster-api-e2e-informing-main
• /test pull-cluster-api-e2e-mink8s-main
• /test pull-cluster-api-e2e-scale-main-experimental
• /test pull-cluster-api-e2e-workload-upgrade-1-27-latest-main
• /test pull-cluster-api-test-mink8s-main

Use /test all to run the following jobs that were automatically triggered:

• pull-cluster-api-apidiff-main
• pull-cluster-api-build-main
• pull-cluster-api-e2e-informing-main
• pull-cluster-api-e2e-main
• pull-cluster-api-test-main
• pull-cluster-api-verify-main

In response to this:

/test ?

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.

[furkatgofurov7]

/test pull-cluster-api-e2e-full-main
/test pull-cluster-api-e2e-workload-upgrade-1-27-latest-main

[furkatgofurov7]

/test pull-cluster-api-e2e-full-main
/test pull-cluster-api-e2e-workload-upgrade-1-27-latest-main

[furkatgofurov7]

/test pull-cluster-api-e2e-full-main
/test pull-cluster-api-e2e-workload-upgrade-1-27-latest-main

[furkatgofurov7]

This is failing in both clusterctl upgrade(cluster class) tests where machines are not coming up properly.

I am guessing it might be due to the wrong templates used in the tests from new v1.5 folder in docker infrastructure, but I copied them over from both v1.4 and main templates to the new v1.5 templates (they have a diff between them), however tests are still failing..

[sbueringer]

This is failing in both clusterctl upgrade(cluster class) tests where machines are not coming up properly.

I am guessing it might be due to the wrong templates used in the tests from new v1.5 folder in docker infrastructure, but I copied them over from both v1.4 and main templates to the new v1.5 templates (they have a diff between them), however tests are still failing..

I also think because of the templates. Not sure what you mean with copying them from both folders :) ("both v1.4 and main templates "). v1.5 should be a copy of the relevant folders from main.

[furkatgofurov7]

/test pull-cluster-api-e2e-full-main

[furkatgofurov7]

I also think because of the templates. Not sure what you mean with copying them from both folders :) ("both v1.4 and main templates "). v1.5 should be a copy of the relevant folders from main.

Sorry being unclear, what I meant is: tried to copy over contents of both 1.4 & main folders to new v1.5 folder previously and run tests. But as I see now, I forgot to change quickstart yaml in both cases, but now new v1.5 content should be identical with main.

[sbueringer]

Changes look good to me now. Unfortunately CI doesn't agree

[furkatgofurov7]

/test pull-cluster-api-e2e-full-main
/test pull-cluster-api-e2e-workload-upgrade-1-27-latest-main

[sbueringer]

Or use the storage version (which is always latest in CAPI) But both fine for me

[furkatgofurov7]

Interesting, now: (v1.0=>current) & ClusterClass (v1.4=>current) are failing but normal (v1.4=>current) or both (v1.5 ==>current) are passing.

I am thinking it is because of we always go with first served:

                for _, gvk := range machineCRD.Spec.Versions {
			if gvk.Served {
				machineListGVK.Version = gvk.Name
				break
			}
		}

since, Versions[] list is sorted and in that case we should have something like:

v1beta1, v1alpha3, v1alpha4 and we always set v1beta in that case to even (v1.0=>current)

[furkatgofurov7]

/test pull-cluster-api-e2e-full-main
/test pull-cluster-api-e2e-workload-upgrade-1-27-latest-main

[chrischdi]

@furkatgofurov7: The following tests 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-workload-upgrade-1-27-latest-main	4db8bf6	link	false	/test pull-cluster-api-e2e-workload-upgrade-1-27-latest-main
pull-cluster-api-e2e-full-main	4db8bf6	link	false	/test pull-cluster-api-e2e-full-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.

Both of these tests did run into different issues I think which are unrelated to the change we did in clusterctl_upgrade.go.

[chrischdi]

Taking a look at pull-cluster-api-e2e-workload-upgrade-1-27-latest-main / link

  [FAILED] Failed to generate the manifest for "cluster-api" / "v1.0.5"
  Unexpected error:
      <*errors.withStack | 0xc00089e378>: 
      failed to get component source YAML from URL: failed to get https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.0.5/core-components.yaml: got status code 503

I think this was a github flake

[chrischdi]

Taking a look at pull-cluster-api-e2e-full-main / link

One test was not able to execute clusterctl. I also guess this was github related, failed fetching the clusterctl binary correctly.

stderr:

Unexpected error:
    <*errors.withStack | 0xc0021d6900>: 
    fork/exec /tmp/clusterctl2208034153: exec format error
    {
        error: <*fs.PathError | 0xc00133bc80>{
            Op: "fork/exec",
            Path: "/tmp/clusterctl2208034153",
            Err: <syscall.Errno>0x8,
        },
        stack: [0x1dc2ac7, 0x1edb145, 0x1f6cb32, 0x84d71b, 0x8618b8, 0x472561],
    }
occurred failed [FAILED] failed to run clusterctl version:

Regarding the second failed e2e inside: This one failed because the machine did not come up.
The machine states that bootstrap did fail DockerMachine:

...
status:
  conditions:
  - lastTransitionTime: "2023-08-10T07:22:47Z"
    message: Repeating bootstrap
    reason: BootstrapFailed
    severity: Warning
    status: "False"
    type: Ready

So I think this was a flake, maybe network related, who knows.

[chrischdi]

Let's drop that sorting and move over to using the Storage version, that should be the most stable one (and there will always be one). We need to rebase anyway.

[furkatgofurov7]

Let's drop that sorting and move over to using the Storage version, that should be the most stable one (and there will always be one). We need to rebase anyway.

Done.

/test pull-cluster-api-e2e-full-main
/test pull-cluster-api-e2e-workload-upgrade-1-27-latest-main

[sbueringer]

Very last nits from my side assuming Prow is happy.
Please also squash directly when fixing the nits

[furkatgofurov7]

Very last nits from my side assuming Prow is happy. Please also squash directly when fixing the nits

@sbueringer @chrischdi thanks both for extensive reviews and help (kudos to @chrischdi for finding a cause of CI failure 🥇). The last run was successful, I squashed all commits into one including the last requested changes by Stefan. PTAL once again.

/test pull-cluster-api-e2e-full-main
/test pull-cluster-api-e2e-workload-upgrade-1-27-latest-main

[sbueringer]

Thank you very much !!

Let's try this again

/lgtm

Will approve once CI is green :)

🤞 🍀 🤞
(I noticed I missed this the last time)

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 0eab8c1063c6e991f7c2866ac67e6166ccf2be3f

[sbueringer]

🎉
/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbueringer

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 [sbueringer]

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

[g-gaston]

/area release