Bug 1576100 - [CRI-O] Stopping runtime on compute node does not trigger 0/1 Ready status
Summary: [CRI-O] Stopping runtime on compute node does not trigger 0/1 Ready status
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node
Version: 3.10.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.10.0
Assignee: Seth Jennings
QA Contact: DeShuai Ma
Depends On:
TreeView+ depends on / blocked
Reported: 2018-05-08 20:23 UTC by Vikas Laad
Modified: 2018-05-09 15:05 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-05-09 15:05:29 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Vikas Laad 2018-05-08 20:23:55 UTC
Description of problem:
Create a cluster with 2 compute nodes, after creating app see where the mysql pod is created. ssh to that node and stop cri-o service. mysql pod never goes to 0/1 Ready state, it stays on 1/1 Ready state. On docker runtime cluster that pod immediately goes to 0/1 ready state. after around 6 mins pod gets recreated on the other Ready node, same time gap noticed for creation on docker runtime cluster also( not sure why the delay is 6 min, could be another bz)

Version-Release number of selected component (if applicable):
openshift v3.10.0-0.32.0
kubernetes v1.10.0+b81c8f8
etcd 3.2.16

How reproducible:
Always on CRIO

Steps to Reproduce:
1. create a cluster with crio runtime
2. create cakephp-mysql app using template
3. ssh to the node where mysql pod is running and stop crio service

Actual results:
No change in pod status for around 6 mins, it shows 1/1 Ready

Expected results:
Pod status should change immediately to 0/1 Ready. Docker runtime behaves correct.

Additional info:

Comment 1 Vikas Laad 2018-05-09 15:05:29 UTC
Created another bz with a better explanation.


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