cri-o: CentOS packaging strategy causes maintenance issues.
Description
Packaging strategy for CentOS causes multiple issues such as bootstraps which used to work suddenly failing and unneeded yum config changes when updating cri-o.
Steps to reproduce the issue:
- Configure yum to point to RPM repos for CentOS. For example https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
Describe the results you received: I can only install a single version of cri-o, currently 1.15.1
Describe the results you expected: I should be able to install any released version of cri-o starting at some “beginning of time” marker, which at least includes all 1.14.x and 1.15.x releases.
Once a version appears in a release repo, it should never disappear as this causes node bootstraps to suddenly fail if they lock down the version.
Output of crio --version:
N/A
Additional environment details (AWS, VirtualBox, physical, etc.):
CentOS 7
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 36 (34 by maintainers)
@lsm5 in a related note, I don’t see any 1.16 crio builds on cbs. Are these going to appear there or are the CentOS packages 1.16 going to be somewhere else?
For those of you following along with this issue, the requests are approved which should result in CRIO being published to buildlogs.centos.org with this commit: https://git.centos.org/centos/cbs-content-control/c/1f5843b9e6690d2307b0d1b98f72073ca5d17d1b?branch=master.
Once the CentOS infrastructure folks figure out why the sync is busted (and presuming the mirroring to buildlogs looks right), the next step is to make another commit to https://git.centos.org/centos/cbs-content-control to publish signed RPMs to mirrors.centos.org.
After all this is done, then all versions of RPMs should be available in stable repos and not just the latest version.
The https://cri-o.io/ documentation still features paas7-crio-311-candidate which uses 1.11 (Jun 2018) As there are lots of configuration changes between cri-o versions, all versions need to be provided…
https://cbs.centos.org/repos/paas7-crio-311-candidate/x86_64/os/
But it would be nice if the link could be updated to at least 1.15, while waiting for 1.17 to appear ? That is the version that the kubernetes documentation (kubeadm) is using, so hopefully it would be alright to use.
https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
Will there be a “paas8” for CentOS 8, or how does that work ?
Do you have to use CoreOS in order to run CRI-O on CentOS ?
@lsm5, I’d be willing to lend a hand to expedite getting the buildlogs setup done, but I’m really not sure where to start. Can you point me in the right direction?
This is my bad in that I’ve yet to make sure buildlogs correctly has the repos setup for cri-o.
We are deploying upstream k8s using custom automation based on terraform and puppet. On node bootstrap, we install RPMs which have their version locked for all components which we install. That way we can first deploy updates in a non-production environment and then graduate them to production.
As an operator, I shouldn’t be forced to always install the latest version. I should be able to perform my own vetting and then promote. With only a single version in the repo, it makes this harder to do. We essentially have to mirror the RPMs somewhere else so that they won’t randomly disappear and break production when a new version comes out.
For kubelet and kubectl, we use the repo http://yum.kubernetes.io/repos/kubernetes-el7-x86_64. In this repo, you can find RPMs for all k8s versions going all the way back to 1.5.4. My preference would be that crio where managed in the same way, a single repo with all versions in it from which I can pick the one I want.