#1 also provides kubernetes-cni for upstream kubeadm compat
Merged 3 months ago by lsm5. Opened 3 months ago by jasonbrooks.
rpms/ jasonbrooks/containernetworking-plugins pr-support-upstream-kubelet  into  master

@@ -23,7 +23,7 @@ 

  

  Name: %{project}-%{repo}

  Version: 0.7.4

- Release: 1%{?dist}

+ Release: 2%{?dist}

  Summary: Libraries for writing CNI plugin

  License: ASL 2.0

  URL: %{git0}

@@ -46,6 +46,7 @@ 

  

  Obsoletes: %{project}-cni < 0.7.1-2

  Provides: %{project}-cni = %{version}-%{release}

+ Provides: kubernetes-cni

  

  %description

  The CNI (Container Network Interface) project consists of a specification

@@ -266,6 +267,9 @@ 

  %endif

  

  %changelog

+ * Wed Feb 27 2019 Jason Brooks <jbrooks@redhat.com> - 0.7.4-2

+ - add Provides kubernetes-cni for compatibility with upstream kubelet package

+ 

  * Wed Feb 13 2019 Lokesh Mandvekar <lsm5@fedoraproject.org> - 0.7.4-1

  - bump to v0.7.4

  

The kubelet package maintained by the kubernetes upstream project, which is used for running kubeadm, depends on a cni plugins package that they call kubernetes-cni. That package can't be used with rpm-ostree, because it installs binaries to `/opt, which rpm-ostree doesn't allow. This containernetworking-plugins package provides the needed cni binaries, but needs this change to satisfy the upstream kubelet's deps.

I guess this should be another line saying "Provides: kubernetes-cni = %{version}-%{release}", else I think rpmlint would complain about unversioned provides. Can you try that out please?

1 new commit added

  • add version to provides
3 months ago

1 new commit added

  • add release
3 months ago

I added it, but the trouble for my use case, right now, at least, is that the upsteam package is requiring kubernetes-cni = 0.6.0, so this won't work -- until/unless they bump it in the future.

Hmm, how about having Provides: kubelet-cni = 0.6.0 temporarily until upstream relaxes that requirement? I know it's a lie but if upstream is having such a strict version requirement, leaving it either unversioned or equal to 0.7.4 would probably not work.

unless you're sure the original unversioned Provides work.

unless you're sure the original unversioned Provides work.

I did test the unversioned Provides, and it worked. It does trigger an rpmlint warning, though. I'm fine w/ lying about kubernetes-cni = 0.6.0, too, if you're all right with it. ;)

I figure a lie of omission is better, though, if we can ignore the rpmlint warning, and leave out the version.

I did test the unversioned Provides, and it worked. It does trigger an rpmlint warning, though. I'm fine w/ lying about kubernetes-cni = 0.6.0, too, if you're all right with it. ;)
I figure a lie of omission is better, though, if we can ignore the rpmlint warning, and leave out the version.

Ack, let's go with the original patch you had in that case. Could you please also bump the release tag and add a changelog entry with the justification for this?

also, please squash commits as well, thanks :)

rebased onto f50486f

3 months ago

Pull-Request has been merged by lsm5

3 months ago

also, please squash commits as well, thanks :)

How about getting this into f30 -- can I send you a PR for that branch?

it merged cleanly on f28, f29 and f30, I just pushed those, will build them now, thanks a lot!

btw, are you interested in co-maintaining this package?

it merged cleanly on f28, f29 and f30, I just pushed those, will build them now, thanks a lot!

thanks!

btw, are you interested in co-maintaining this package?

Sure, I can co-maintain it.