package kubelet and cni plugins in RPMs

[mikedanese]

We should have seperate RPMs for cni plugins and kubelet. They should depend on a compatible docker version. They should be built and published during the release process.

cc @dgoodwin

[ingvagabund]

@mikedanese @dgoodwin can you be more descriptive what is intent of this PR?

[dgoodwin]

I'm just starting to look into this, but I think I should check that everyone is in agreement it's worth doing and make sure I understand the goals.

Kubernetes RPMs are available out of the box today with Fedora / RHEL / CentOS and have had a lot of effort put into them. They originate from a relatively large specfile that builds from source and applies relevant patches for the distros, sub-packages for master/node/client tools and it looks like one that can be used as a golang dependency. They also require the "docker" rpm we ship in our distribution, as opposed to "docker-engine" from Docker.

So benefits to doing another dramatically simplified spec file here (built by just fetching the upstream binary), we could likely get these packages out a little quicker than the Fedora packagers can react after a new release, it would work with the upstream docker-engine rpm, and theoretically work on other not RedHat rpm based distributions. Any other benefits I'd be missing?

Drawbacks however, there will probably not be as many eyes on these packages and the experience may not be as good as the one we can offer with kubernetes in the distributions themselves.

Are their benefits I'm missing, and if not do we feel this is sufficient to be worth pursuing?

[ingvagabund]

So benefits to doing another dramatically simplified spec file here (built by just fetching the upstream binary), we could likely get these packages out a little quicker than the Fedora packagers can react after a new release,

So the task here is to provide a general rpm for various distributions that will fetch the kubelet (and possibly other binaries) from kubernetes/kubernetes releases?

it would work with the upstream docker-engine rpm, and theoretically work on other not RedHat rpm based distributions.

Kubernetes supports rkt as well. It would make more sense to have a requirement on a virtual provide (e.g. container-tech) that would by provided by installed docker, docker-engine, rkt or any other container technology implementation. Of course, one component conflicting with each other.

Any other benefits I'd be missing?

Drawbacks however, there will probably not be as many eyes on these packages and the experience may not be as good as the one we can offer with kubernetes in the distributions themselves.

Agree. Each distribution has in general different names of components, different dependencies, different installation paths, etc.

Are their benefits I'm missing, and if not do we feel this is sufficient to be worth pursuing?

[detiber]

I see there being two options that we have here.

1. Publishing a repo specific for this use case, for which I would probably recommend distributing through COPR.
2. Working with the upstream SIGs for Fedora/CentOS to align release schedules through their channels.

Granted 2 wouldn't support other RPM-based distros...

[mikedanese]

cc @mansoorj @kelseyhightower @kubernetes/sig-cluster-lifecycle

[errordeveloper]

cc kubernetes/kubernetes#26093

[dgoodwin]

Just getting back from vacation but an update of where things were before, in meeting we discussed and decided that yes, there is a desire for upstream k8s to publish an RPM as part of the build process. I've got a spec file working, we discussed how it would be built and integrated into the release process on slack as it requires RPM tooling to do so, and decided a Docker container to build would likely be best. I'm just rounding out that process now and hopefully will have something up this week.

[luxas]

This is now fixed. Yay!