Bug 633356

Summary:	[6.1 FEAT] Enhance cio_ignore usage in scripts using new handler for pending work - initscripts part
Product:	Red Hat Enterprise Linux 6	Reporter:	IBM Bug Proxy <bugproxy>
Component:	s390utils	Assignee:	Dan Horák <dhorak>
Status:	CLOSED DUPLICATE	QA Contact:	qe-baseos-daemons
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.1	CC:	azelinka, dhorak, gmuelas, jjarvis, maier, nobody+PNT0273897, notting, ovasik, sbest
Target Milestone:	beta	Keywords:	FutureFeature, Reopened
Target Release:	6.1
Hardware:	s390x
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-11-30 20:14:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	538808, 580566, 633469, 633862

Description IBM Bug Proxy 2010-09-13 16:23:04 UTC

1. Feature Overview:
Feature Id: [67038]
a. Name of Feature: [6.1 FEAT] Enhance cio_ignore usage in scripts using new handler for pending
work - initscripts part
b. Feature Description
This feature requests to enhance the cio_ignore usuage in initscripts by taking advantage of the new
cio_ignore handler to wait for cio pending work.


2. Feature Details:
Sponsor: LTC zSeries BOE
Architectures:
  zSeries - 64 native, 

Arch Specificity: purely arch specific code
Affects Kernel Modules: Field does not exist
Delivery Mechanism: LDP Deliverable
Category: other
Request Type: Code Development Support from Distributor
d. Upstream Acceptance: Field does not exist
Sponsor Priority P1
f. Severity: ship issue
IBM Confidential: No
Code Contribution: 3rd party code
g. Component Version Target:
---

3. Business Case
This feature will avoid running into possible race condition, making the code more stable. 
Resulting on less service cost and better customer satisfation.

4. Primary contact at Red Hat:
John Jarvis
jjarvis

5. Primary contacts at Partner:
Project Management Contact:
Hans-Georg Markgraf, mgrf.com

Technical contact(s):
Gonzalo Muelas Serrano, gmuelas.com

Comment 2 Bill Nottingham 2010-09-13 18:14:26 UTC

initscripts do not touch cio_ignore.

Comment 3 Gonzalo Muelas Serrano 2010-09-14 10:21:18 UTC

Hello,
the changes needed to implement this feature are to use the kernel
infrastructure (provided by RH Bug 631517) and the tool (provided by RH Bug
631527) in the scripts when booting the system to solve the issues workarounded with timeouts in RHEL 6.0. For more deatils, please read RH Bug 533494 comments #15 through #35, and get in contact with Dan Horak.

If the boot process just call some scripts done by Dan Horak, then is fine with me to reassign it to Dan Horak.

Comment 4 Steffen Maier 2010-09-14 12:41:18 UTC

This one is a follow-up on
RH Bug 561339 - [LTC 6.0 FEAT] 201085: unmask and wait for devices, initscripts part
which was originally created for initscripts but ended up in s390utils being triggered by an upstart event early during boot. Sorry for the confusion.

A new kernel interface to reliably block until dynamic free of devices from cio_ignore helps removing no longer necessary waiting loop code from device_cio_free and thus improves maintenance of this s390utils tool.

In order not to loose this part of the feature, reopening and reassigning to s390utils.

Comment 5 IBM Bug Proxy 2010-10-04 16:35:24 UTC

------- Comment From rsisk.com 2010-10-04 10:42 EDT-------
Code Upstream Status: No Code Required

Comment 8 IBM Bug Proxy 2010-11-30 10:11:19 UTC

------- Comment From mgrf.com 2010-11-30 05:05 EDT-------
Close this feature request as duplicate
to   66875 - RHBZ 631527 -  [6.1 FEAT] Provide userspace handle to wait for cio
pending work - userspace

The functionality could be implemented into s390tools (s390utils) only and get referred to during install and boot.
The calls from installer and scripts already exist with RHEL6  (6.0 FEAT cio_ignore...)  feature request.
.
So nothing to implement for initscripts anymore.

*** This bug has been marked as a duplicate of bug 66875 ***

Comment 9 John Jarvis 2010-11-30 20:14:33 UTC


*** This bug has been marked as a duplicate of bug 631527 ***