build(deps): bump github.com/containerd/containerd from 1.6.19 to 1.7.0

[dependabot]

Bumps github.com/containerd/containerd from 1.6.19 to 1.7.0.

Release notes

Sourced from github.com/containerd/containerd's releases.

containerd 1.7.0

Welcome to the v1.7.0 release of containerd!

The eighth major release of containerd includes new functionality alongside many improvements. This release is the last major release of containerd 1.x before 2.0. Some functionality in this release may be considered experimental or unstable, but will become stable or default in 2.0. This release still adheres to our backwards compatibility guarantees and users who do not use or enable new functionality should use this release with the same stability expectations. The previous 1.6 release has also become a long term stable release for users who prefer releases with mostly stability improvements and wish to wait a few releases for new functionality.

Highlights

Sandbox API (experimental)

The sandbox API provides a new way of managing containerd's shim, providing more flexibility and functionality for multi-container environments such as Pods and VMs. This API makes it easier to manage these groups of containers at a higher level and offers new extension points for shim implementations and clients.

• Sandbox API (#6703)
• CRI Sandbox API Implementation (#7228)

Transfer Service (experimental)

• Transfer Service (#7320)

The transfer service provides a simple interface to transfer artifact objects between any source and destination. This allows for pull and push operations to be done in containerd whether requested from clients or plugins. It is experimental in this release to allow for further plugin development and integration into existing plugins.

See the Transfer Docs

NRI (experimental)

• Extend NRI scope (nri#16)
• Support for updated NRI (#6019)

The Node Resource Interface is a common framework for plugging extensions into OCI-compatible container runtimes. It provides basic mechanisms for plugins to track the state of containers and to make limited changes to their configuration.

This release introduces NRI v0.3.0 with an updated plugin interface to cover a wide range of use cases.

See the NRI Docs

Platform Support

• Linux containers on FreeBSD (#7000)

Runtime Features

• Add support for CDI device injection (#6654)
• Support for cgroups blockio (#5490)
• Add restart policy for enhanced restart manager (#6744)

... (truncated)

Changelog

Sourced from github.com/containerd/containerd's changelog.

Versioning and Release

This document details the versioning and release plan for containerd. Stability is a top goal for this project, and we hope that this document and the processes it entails will help to achieve that. It covers the release process, versioning numbering, backporting, API stability and support horizons.

If you rely on containerd, it would be good to spend time understanding the areas of the API that are and are not supported and how they impact your project in the future.

This document will be considered a living document. Supported timelines, backport targets and API stability guarantees will be updated here as they change.

If there is something that you require or this document leaves out, please reach out by filing an issue.

Releases

Releases of containerd will be versioned using dotted triples, similar to Semantic Version. For the purposes of this document, we will refer to the respective components of this triple as <major>.<minor>.<patch>. The version number may have additional information, such as alpha, beta and release candidate qualifications. Such releases will be considered "pre-releases".

Major and Minor Releases

Major and minor releases of containerd will be made from main. Releases of containerd will be marked with GPG signed tags and announced at https://github.com/containerd/containerd/releases. The tag will be of the format v<major>.<minor>.<patch> and should be made with the command git tag -s v<major>.<minor>.<patch>.

After a minor release, a branch will be created, with the format release/<major>.<minor> from the minor tag. All further patch releases will be done from that branch. For example, once we release v1.0.0, a branch release/1.0 will be created from that tag. All future patch releases will be done against that branch.

Pre-releases

Pre-releases, such as alphas, betas and release candidates will be conducted from their source branch. For major and minor releases, these releases will be done from main. For patch releases, these pre-releases should be done within the corresponding release branch.

While pre-releases are done to assist in the stabilization process, no guarantees are provided.

... (truncated)

Commits

• 1fbd703 Merge pull request #8242 from dmcgowan/prepare-v1.7.0
• e13a916 Prepare release notes for v1.7.0
• e92e692 Merge pull request #8241 from AkihiroSuda/deprecation-20230309
• 0fe3b49 Merge pull request #8232 from panguicai008/flag-usage
• 2168015 Merge pull request #8240 from davidhsingyuchen/client-install-doc
• 625217d RELEASES.md: describe the deprecated config properties
• 8cc09e6 Merge pull request #8233 from dmcgowan/prepare-v1.7.0-rc.3
• 703e2ba docs: link docs/managed-opt.md to client.Install
• 1f236dc Merge pull request #8237 from AkihiroSuda/go-1.20.2
• f2bb9c9 Go 1.20.2
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dependabot[bot]
Once this PR has been reviewed and has the lgtm label, please assign giuseppe for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[rhatdan]

@vrothberg @cevich any idea why the vendoring is always broken on these updates?

[cevich]

The Renovate flavored update is similarly broken: #4652

[cevich]

@mtrmac IIRC you made a comment relating to this recently. I believe the gist was: The most optimal solution is doing the manual grunt-work to make it right. I don't know how golang modules & vendoring works well enough to comment further.

I know in the case of renovate, there's an option to run go mod tidy after applying the dependency update. I'm guessing that's why that PR "looks" worse from a CI perspective.

If I have a vote, I'd actually prefer the renovate PR gets fixed and merged as opposed to this one. Since the point is to phase-out Dependabot.

[mtrmac]

Those seem to be different problems to me:

• fix(deps): update module github.com/containerd/containerd to v1.7.0 - autoclosed #4652 (comment) is, I think, best fixed by removing the 1.17 version from

  buildah/Makefile

  Line 192 in bae9047

  GO111MODULE=on $(GO) mod tidy -compat=1.17

  , and manually running that go mod tidy -go=1.16 && go mod tidy -go=1.17 command. If I made a comment, it might have been something to this effect.
• This PR seems to fail on just go.sum differences; as a very lazy guess it might be worth checking if updating

  buildah/.cirrus.yml

  Line 123 in bae9047

  image: docker.io/library/golang:1.17

  to a more recent version would make a difference.

[mtrmac]

• This PR seems to fail on just go.sum differences; as a very lazy guess it might be worth checking if updating

  buildah/.cirrus.yml

  Line 123 in bae9047

  image: docker.io/library/golang:1.17

  
  to a more recent version would make a difference.

Testing that, running the existing go mod tidy -compat=1.17 with go version go1.20.1 darwin/amd64 removes entries similarly; so it’s not that Dependabot is using a newer version of Go than this repo — and perhaps it’s similarly a consequence of go mod tidy failing.

[mtrmac]

@cevich I have manually updated the Renovate PR. I’m not at all sure it works better that way, see that PR for a more detailed explanation.

[mtrmac]

Oh… here is me lazily spinning theories, while Renovate Has An Option For That™️ : https://docs.renovatebot.com/modules/manager/gomod/ has flags like gomodTidy1.17. So that’s another option.

Looking a bit further, maybe the ideal fix is to bump the go version in go.mod from 1.17 to 1.18:

• 1.18 is required anyway per Update to Go 1.18 image#1827
• doing that would make the difference between go mod tidy and go mod tidy -compat=1.17 disappear (I think, per go help mod tidy
• … and then we could use go mod tidy without a hard-coded version, removing one location to update.

[mtrmac]

Filed #4662, let’s see… Then we can let the tools rebase their PRs, and we’ll see if that actually helped.

[dependabot]

Looks like github.com/containerd/containerd is up-to-date now, so this is no longer needed.