Bug 2009785 - CRI-O's version file should be pinned by MCO
Summary: CRI-O's version file should be pinned by MCO
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node
Version: 4.10
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.10.0
Assignee: Peter Hunt
QA Contact: Sunil Choudhary
Depends On:
TreeView+ depends on / blocked
Reported: 2021-10-01 14:56 UTC by Peter Hunt
Modified: 2022-03-10 16:15 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2022-03-10 16:14:46 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift machine-config-operator pull 2776 0 None open crio: specifically enable version_file_persist 2021-10-01 14:56:53 UTC
Red Hat Product Errata RHSA-2022:0056 0 None None None 2022-03-10 16:15:06 UTC

Description Peter Hunt 2021-10-01 14:56:23 UTC
Description of problem:
Currently, openshift and upstream CRI-O diverge on their recommendation for crio wipe. upstream users have reported confusion at the enabling of crio wipe by default, but it is vital to the health of self upgrading openshift.

At present, the crio config field for crio wipe is not configured by the MCO. this has worked fine, but the upstream plans on changing the default to allow upstream users to continue to not have it enabled by default. as such, it should be pinned in MCO

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. cat /etc/crio/crio.conf.d/* | grep version_file_persist

Actual results:
empty results

Expected results:
should contain /var/lib/crio/version

Additional info:

Comment 3 Sunil Choudhary 2021-10-27 11:07:23 UTC
Verified on 4.10.0-0.nightly-2021-10-25-190146

$ oc get clusterversion
NAME      VERSION                              AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.10.0-0.nightly-2021-10-25-190146   True        False         3h49m   Cluster version is 4.10.0-0.nightly-2021-10-25-190146

$ oc get nodes
NAME                                         STATUS   ROLES    AGE     VERSION
ip-10-0-156-16.us-east-2.compute.internal    Ready    worker   3h59m   v1.22.1+674f31e
ip-10-0-159-78.us-east-2.compute.internal    Ready    master   4h7m    v1.22.1+674f31e
ip-10-0-179-69.us-east-2.compute.internal    Ready    worker   3h59m   v1.22.1+674f31e
ip-10-0-184-212.us-east-2.compute.internal   Ready    master   4h6m    v1.22.1+674f31e
ip-10-0-196-149.us-east-2.compute.internal   Ready    master   4h7m    v1.22.1+674f31e
ip-10-0-219-207.us-east-2.compute.internal   Ready    worker   4h      v1.22.1+674f31e

$ oc debug node/ip-10-0-156-16.us-east-2.compute.internal
Starting pod/ip-10-0-156-16us-east-2computeinternal-debug ...

sh-4.4# cat /etc/crio/crio.conf.d/* | grep version_file_persist
version_file_persist = "/var/lib/crio/version"

Comment 6 errata-xmlrpc 2022-03-10 16:14:46 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.