packages: Reintroduce kubernetes-cni package at v0.8.6

[justaugustus]

What type of PR is this?

/kind regression

What this PR does / why we need it:

Release Managers have been thinking over a mitigation for this in https://kubernetes.slack.com/archives/C2C40FMNF/p1592480243361500 (public channel) and https://kubernetes.slack.com/archives/GKEA5EL67/p1592845895001700 (private channel - only accessible to Release Managers).

Following the Slack chat, Tim and I spoke at length about potential options.

1. Repackage (Do not conflict kubernetes-cni package for RPMs #1367)

   Remove the Obsoletes: kubernetes-cni option (rpms) from the kubelet package.
   This keeps the CNI plugins bundled with the kubelet, but prevents the kubelet from obsoleting older kubernetes-cni packages, which has the unintended side-effect of requiring kubelet >= 1.18.4

   We would then repackage debs/rpms, bumping the revision numbers to 01 and 1, respectively.

2. Reintroduce the kubernetes-cni package and repackage (this PR)

   An alternate approach, which is closer to what we had before is this PR.

   Here we:

   • selectively "revert" Bundle CNI plugins (v0.8.6) in kubelet deb/rpm packages #1309, which restores the kubernetes-cni package
   • update the kubernetes-cni package definitions to build against CNI plugins v0.8.6

   This should prevent the kubelet package from conflicting with other packages that happen to provide kubernetes-cni, as detailed in kubelet-1.18.4-0 cannot be installed alongside cri-o on fedora 32 #1371 bug report.

   We would then repackage debs/rpms, bumping the revision numbers to 01 and 1, respectively.

Signed-off-by: Stephen Augustus saugustus@vmware.com

/priority critical-urgent
/assign @tpepper @saschagrunert @cpanato @hasheddan
cc: @kubernetes/release-engineering

Which issue(s) this PR fixes:

Should address kubernetes/kubernetes#92242, #1371, kubernetes-sigs/image-builder#259.
Supersedes #1367.

Special notes for your reviewer:

WIP. Still need to add the RPM bits back.
Also, I'm explicitly leaving kubepkg as out-of-scope for this PR, since it's not currently in use and might slow down this PR.

Does this PR introduce a user-facing change?

packages: Reintroduce kubernetes-cni package at v0.8.6

[justaugustus]

/test all
/hold for review

[saschagrunert]

/lgtm

[tpepper]

Great description of options in the PR message.

A few additional points of clarity to note explicitly:

• path Improve pre-release reporting dashboard #2 is the one be attempted here
• selective revert of Bundle CNI plugins (v0.8.6) in kubelet deb/rpm packages #1309 and reintroduction of kubernetes-cni will specifically include removal from kubelet package spec all of the additions of all three of these:
  • Provides: kubernetes-cni
  • Conflicts: kubernetes-cni
  • Replaces: kubernetes-cni
• A downside of this approach is it continues to have us serving a notably newer kubernetes-cni than the one tested and validated with prior releases. Using our repo for a simple yum/dnf install or upgrade will not give a consumer what they probably actually want if they're not specifying package name-version-release tuples explicitly. This has already always been the case and is a long term issue we're working to address.

Hopefully we don't trigger yet another surprising oddity in how the yum/dnf clients interact with our repo.

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justaugustus, saschagrunert, tpepper

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:

• packages/deb/OWNERS [justaugustus,tpepper]
• packages/rpm/OWNERS [justaugustus,tpepper]

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

[justaugustus]

Thanks for adding the additional context from our chats here, @tpepper!
/hold cancel