In response to this:

- What I did

For a while now, CRI-O can attempt to repair the storage directory on start-up following an unclean shutdown, such as a node crash or unexpected restart. This allows CRI-O to recover from a storage directory corruption, alleviating potential crashes or termination with a fatal error once it's started back up.

However, this internal repair feature has to be enabled to take effect, so it's currently an opt-in solution. This feature has matured and can be turned on as the new default when deploying OpenShift clusters. As a result, our customers will benefit from improved cluster resilience.

Thus, turn the internal feature on as the new default.

Related:

• Use custom storage check options for CRI-O internal wipe cri-o/cri-o#8417
• make use of c/storage Check() and Repair() functions cri-o/cri-o#7177

- How to verify it

Deploy updated configuration manually or using either the Machine Config Operator.

Then, to verify the internal repair feature working, proceed using the following steps:

(assuming that the test will be performed using an OpenShift cluster with privileged access available)

1. Stop kubelet and CRI-O services
2. Navigate to the /var/lib/containers directory
3. Remove a random layer from any of the available container images (to corrupt the storage directory)
4. Remove the /var/lib/crio/clean.shutdown file to simulate CRI-O unclean shutdown
5. Start CRI-O and kubelet services
6. Verify that both services are working correctly
7. Verify that CRI-O run the check and repair to fix the corrupted storage directory on start-up (see service logs)

- Description for the changelog

Change the internal repair option to be enabled by default.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

In response to this:

/cherry-pick release-4.17

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

In response to this:

- What I did

For a while now, CRI-O can attempt to repair the storage directory on start-up following an unclean shutdown, such as a node crash or unexpected restart. This allows CRI-O to recover from a storage directory corruption, alleviating potential crashes or termination with a fatal error once it's started back up.

However, this internal repair feature has to be enabled to take effect, so it's currently an opt-in solution. This feature has matured and can be turned on as the new default when deploying OpenShift clusters. As a result, our customers will benefit from improved cluster resilience.

Thus, turn the internal feature on as the new default.

Related:

• Use custom storage check options for CRI-O internal wipe cri-o/cri-o#8417
• make use of c/storage Check() and Repair() functions cri-o/cri-o#7177

- How to verify it

Deploy updated configuration manually or using either the Machine Config Operator.

Then, to verify the internal repair feature working, proceed using the following steps:

(assuming that the test will be performed using an OpenShift cluster with privileged access available)

1. Stop kubelet and CRI-O services
2. Navigate to the /var/lib/containers directory
3. Remove a random layer from any of the available container images (to corrupt the storage directory)
4. Remove the /var/lib/crio/clean.shutdown file to simulate CRI-O unclean shutdown
5. Start CRI-O and kubelet services
6. Verify that both services are working correctly
7. Verify that CRI-O run the check and repair to fix the corrupted storage directory on start-up (see service logs)

- Description for the changelog

Change the internal repair option to be enabled by default.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

In response to this:

- What I did

For a while now, CRI-O can attempt to repair the storage directory on start-up following an unclean shutdown, such as a node crash or unexpected restart. This allows CRI-O to recover from a storage directory corruption, alleviating potential crashes or termination with a fatal error once it's started back up.

However, this internal repair feature has to be enabled to take effect, so it's currently an opt-in solution. This feature has matured and can be turned on as the new default when deploying OpenShift clusters. As a result, our customers will benefit from improved cluster resilience.

Thus, turn the internal feature on as the new default.

Related:

• Use custom storage check options for CRI-O internal wipe cri-o/cri-o#8417
• make use of c/storage Check() and Repair() functions cri-o/cri-o#7177

- How to verify it

Deploy updated configuration manually or using either the Machine Config Operator.

Then, to verify the internal repair feature working, proceed using the following steps:

(assuming that the test will be performed using an OpenShift cluster with privileged access available)

1. Stop kubelet and CRI-O services
2. Navigate to the /var/lib/containers directory
3. Remove a random layer from any of the available container images (to corrupt the storage directory)
4. Remove the /var/lib/crio/clean.shutdown file to simulate CRI-O unclean shutdown
5. Start CRI-O and kubelet services
6. Verify that both services are working correctly
7. Verify that CRI-O run the check and repair to fix the corrupted storage directory on start-up (see service logs)

- Description for the changelog

Change the internal repair option to be enabled by default.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

• templates/master/01-master-container-runtime/OWNERS [haircommander]
• templates/worker/01-worker-container-runtime/OWNERS [haircommander]

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

In response to this:

/cherry-pick release-4.17

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.