Back to bug 1740463

Who When What Removed Added
Vikhyat Umrao 2019-08-13 15:39:03 UTC CC vumrao
Rachana Patel 2019-08-13 15:46:09 UTC Blocks 1727980
Ashish Singh 2019-08-14 04:18:06 UTC CC assingh
Tejas 2019-08-20 08:52:50 UTC Priority unspecified medium
Target Release 4.0 3.3
CC tchandra
Target Milestone rc z1
PnT Account Manager 2019-09-02 10:12:42 UTC CC sankarshan
Dimitri Savineau 2019-09-11 13:48:39 UTC CC tserlin
CC dsavinea
Target Milestone z1 z2
Tejas 2019-10-22 05:51:13 UTC Priority medium high
Dimitri Savineau 2019-10-25 16:37:38 UTC Target Milestone z2 z3
Bara Ancincova 2019-11-06 10:21:45 UTC Blocks 1726134
Docs Contact bancinco
Doc Text .Upgrading OSDs can become unresponsive for a long period of time

When using the `rolling_update.yml` playbook to upgrade an OSD, the playbook waits for the `active+clean` state. When data and `no of retry` count is large, the upgrading process becomes unresponsive for a long period of time because the playbook sets the `noout` and `norebalance` flags instead of the `nodeep-scrub` flag.
Doc Type If docs needed, set a value Known Issue
Bara Ancincova 2019-11-18 11:01:36 UTC Blocks 1726134 1726135
Guillaume Abrioux 2019-11-20 14:43:14 UTC Status NEW ASSIGNED
Guillaume Abrioux 2019-11-20 14:43:50 UTC Link ID Github ceph/ceph-ansible/pull/4757
Guillaume Abrioux 2020-02-03 14:22:47 UTC Status ASSIGNED POST
Ken Dreyer (Red Hat) 2020-02-19 21:52:47 UTC Target Milestone z3 z4
Ken Dreyer (Red Hat) 2020-02-20 19:32:33 UTC Status POST MODIFIED
CC kdreyer
Fixed In Version RHEL: ceph-ansible-3.2.39-1.el7cp Ubuntu: ceph-ansible_3.2.39-2redhat1
errata-xmlrpc 2020-02-20 21:02:11 UTC Status MODIFIED ON_QA
Bara Ancincova 2020-03-16 10:00:50 UTC CC gabrioux
Doc Text .Upgrading OSDs can become unresponsive for a long period of time

When using the `rolling_update.yml` playbook to upgrade an OSD, the playbook waits for the `active+clean` state. When data and `no of retry` count is large, the upgrading process becomes unresponsive for a long period of time because the playbook sets the `noout` and `norebalance` flags instead of the `nodeep-scrub` flag.
.Upgrading OSDs is no longer unresponsive for a long period of time

Previously, when using the `rolling_update.yml` playbook to upgrade an OSD, the playbook waited for the `active+clean` state. When data and `no of retry` count was large, the upgrading process became unresponsive for a long period of time because the playbook set the `noout` and `norebalance` flags instead of the `nodeep-scrub` flag. With this update, the playbook sets the correct flag, and the upgrading process is no longer unresponsive for a long period of time.
Doc Type Known Issue Bug Fix
Flags needinfo?(gabrioux)
Vasishta 2020-03-16 13:02:49 UTC Depends On 1813905
Vasishta 2020-03-17 15:32:58 UTC Status ON_QA VERIFIED
Guillaume Abrioux 2020-03-18 07:54:30 UTC Flags needinfo?(gabrioux)
errata-xmlrpc 2020-04-03 16:41:46 UTC Status VERIFIED RELEASE_PENDING
errata-xmlrpc 2020-04-06 08:27:04 UTC Status RELEASE_PENDING CLOSED
Resolution --- ERRATA
Last Closed 2020-04-06 08:27:04 UTC
errata-xmlrpc 2020-04-06 08:27:46 UTC Link ID Red Hat Product Errata RHBA-2020:1320
Red Hat One Jira (issues.redhat.com) 2023-09-07 20:26:04 UTC Link ID Red Hat Issue Tracker RHCEPH-7355

Back to bug 1740463