update default base, node image

[BenTheElder]

"promoted" (crane cp) from https://prow.k8s.io/view/gs/kubernetes-ci-logs/logs/post-kind-push-base-image/1897268305459154944

TODO: node image

[stmcginnis]

crane manifest docker.io/kindest/base:v20250305-2d7b9fe8
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
  "manifests": [
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "digest": "sha256:efdda7bfdb9dd1300a7750c80eda96a602b750dc9e3eb54065cc4060d7f4c057",
      "size": 504,
      "platform": {
        "architecture": "amd64",
        "os": "linux"
      }
    },
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "digest": "sha256:ff3ff004ef18783ff57c54824c04e3f7b9e74bb826dea880e234f8bef8a98754",
      "size": 504,
      "platform": {
        "architecture": "arm64",
        "os": "linux"
      }
    }
  ]
}

/lgtm

[BenTheElder]

We should probably revisit if the github actions jobs depend on doing this, versus something like kind build node-image $latest-stable-k8s-version automatically since they don't need to compile k/k now.

Then anyone could actually fully test a new base, kindnetd, etc image changes in presubmit (by using the staging auto-builds) without also having to push a node image.

[BenTheElder]

We get a lot of coverage from the prowjobs, but we miss if these somehow break podman/nerdctl/rootless environments currently, until we attempt the default-node image bump.

TBF, we also don't really test source changes to the base image / kindnetd / ... until after the image is built in post-submit, but it's going to get really slow and painful if we build and override all of these from source all the time ... and we do auto-build and push those currently (granted it does not push to dockerhub yet, but if we were on registry.k8s.io you'd have to go file an image promotion PR and wait for the promoter to run anyhow)

[BenTheElder]

probably #3865 first

[BenTheElder]

Well this passed everything so I'll actually update the node image as well

[BenTheElder]

I think the podman actions are flaking now unrelated, they also fail on rebasing the empty PR in #648

But I'd like to see them passing, will look at that.

[BenTheElder]

ERROR: Untarring "/var/log": error writing to /tmp/kind/logs/kind-control-plane/containers/kube-controller-manager-kind-control-plane_kube-system_kube-controller-manager-14057fabb81fa80d66f295833dce6e52bc52013a2ca199928eee47cd3bebab53.log: unexpected EOF: error writing to /tmp/kind/logs/kind-control-plane/containers/kube-controller-manager-kind-control-plane_kube-system_kube-controller-manager-14057fabb81fa80d66f295833dce6e52bc52013a2ca199928eee47cd3bebab53.log: unexpected EOF

This is happening in #648

The error comes from our own little untar utility, maybe the podman exec was killed before we finish getting the tar output?

https://github.com/kubernetes-sigs/kind/actions/runs/13685685537/job/38268468982?pr=648

[BenTheElder]

worth noting this runs podman 3.4.4 which is super old

[BenTheElder]

I think they will work fine after #3888 which gets us on a more recent release

for the others, I think we should keep testing older / stable primarily, to avoid depending on new features

[BenTheElder]

It's annoying that actions continues to use the version of the workflow in my branch instead of what is in master, I'll have to rebase to get the fix in #3888

[aojea]

It's annoying that actions continues to use the version of the workflow in my branch instead of what is in master, I'll have to rebase to get the fix in #3888

I think they added a rebase button, no?

[BenTheElder]

I think they added a rebase button, no?

I don't think so, but rebasing also invalidates all of the prow CI that intelligently handles this sort of thing otherwise and may take longer to run (major e2es)

[BenTheElder]

There's no rebase button because there are no merge conflicts, the only problem is that the actions workflow is out of date, so it's missing the fixes.

And in general, you can't trust actions results on PRs because they may have been submitted from an old branch and be missing current settings / tests.

Actions is really nice for automating github, but it has been a bit disappointing for testing PRs.

[aojea]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aojea, BenTheElder

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 [BenTheElder,aojea]

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